Reassemble under OSX

[roc_p2]

Under OSX, is it possible to somehow reassemble the asm file created with "pbcompiler -c", and if yes, how?

[Keya]

the short answer is - by design, yes! i think its great how Purebasic lets us generate .asm files so we can play with them before assembling, talk about freedom! makes it easier to learn too
I've never tried it on OSX, but it was fairly easy when i last tried in Windows, the only thing to remember is that PB uses FASM for Windows/Linux but uses YASM for OSX. Compiling might be as simple as running "./yasm pboutput.asm" (or perhaps another flag is needed to specify the output file, try "yasm --help" there). Im sure this would've already been discussed too so in the meantime search the forum for yasm

[roc_p2]

Thank you for your comment. Unfortunately, under OSX the simple option to reassemble the asm file and create an executable file from this asm file is not implemented in the PureBasic program, as apparently it is the case for Windows.

Indeed, the compilation of the asm file is straightforward in OSX (with yasm or nasm) and one gets an object file, but I've not yet been able to successfully perform the second important step of further linking this object file with the right libraries to create an executable file (e.g. with the ld tool). Any ideas?

[Keya]

i would just temporarily rename the compiler binaries like yasm.exe etc one-by-one, replacing them with a simple 'proxy' app that did nothing other than save the commandline parameters to a file, so you can see what parameters Purebasic was using

[roc_p2]

Thank you, done. In my example, the ld tool is given about 70 parameters by the way... No wonder it hadn't worked on my first try.
Apparently, the pbcompiler writes the actual libraries (libnames.a) in the /tmp directory, but deletes them immediately after linking, I don't know why.

[Keya]

fantastic! could you please post an example of the commandlines needed to compile?

[Danilo]

Hmm, /REASM is indeed only supported on Windows.

Apparently, the pbcompiler writes the actual libraries (libnames.a) in the /tmp directory,
but deletes them immediately after linking, I don't know why.

The extracted libs are not required anymore after linking, so PB can safely delete them.
If you still need them, your stub could make a copy of the libs.

[roc_p2]

Well, so here is my solution under OSX 64bit to reassemble an assembly file created by Purebasic from the console (tested with the 2DDrawing example on OSX 10.11.4):

0) extract the libraries in the folder purelibraries to get the needed .a files (e.g. with a stub ld program which copies the temporary libraries to another folder)
1) compile the pb file creating the asm file: "pbcompiler -c filename.pb" ==> purebasic.asm
2) assemble the asm file with yasm creating the object file: "yasm -O1 -f macho64 -s -o purebasic.o purebasic.asm" ==> purebasic.o
3) link the object file to the needed libraries with ld, creating the executable: "ld -dynamic -arch x86_64 -macosx_version_min 10.6 -weak_reference_mismatches non-weak -o /desired_path_for_executable/2DDrawing -lcrt1.10.6.o -L/path_to_PureBasic/purelibraries/macos/libraries -L/path_to_extracted_libraries.a/ -L/usr/local/Cellar/gcc/5.3.0/lib/gcc/5/gcc/x86_64-apple-darwin15.0.0/5.3.0 -L/usr/local/Cellar/gcc/5.3.0/lib/gcc/5/gcc/x86_64-apple-darwin15.0.0/5.3.0/../../.. purebasic.o Internal.a 2DDrawing.a Image.a ImagePluginBMP.a ImagePlugin.a Memory.a Cocoa.a Menu.a Window.a Event.a Map.a VectorDrawing.a Gadget.a LinkedList.a /path_to_PureBasic/compilers/objectmanager.a SimpleList.a Date.a System.a -framework Carbon -framework Cocoa /path_to_PureBasic/compilers/systembase.a /path_to_PureBasic/compilers/stringutility.a /path_to_PureBasic/compilers/stringmanager.a /path_to_PureBasic/compilers/systembase.a /path_to_PureBasic/compilers/unicodefunctions.a -lstdc++ -lc -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc"

Most of the ld command in step 3 is a listing of the needed libraries. How does one know which libraries to link to? Well, the needed PureBasic libraries are nicely listed in the header of the asm file. Furthermore, other libraries are given in the compiler folder as well as in the purelibraries/macos/libraries folder. As for the other system libraries, I've yet to find out, I guess these are more or less always the same.

Thank you for your support!

(Next steps? Well, it would seem that the above procedure could be automatised, so why not just create the missing reasm program for OSX...)

[Keya]

great, thanks for sharing the process!
like you said it looks like a lot of that could be automated with a simple reasm.pb app that read the .asm file, copied the libs over etc

"yasm -O1

interesting, im guessing that's for optimization? disappointing that fasm has no optimization options. Yasm supports Windows/Linux/OSX so its interesting PB uses fasm for Win/Linux and yasm for OSX, but im guessing thats because OSX support was added after Win/Linux which were already fasm-based, and there's no fasm for OSX! i wonder if many changes are required to compile PB .asm output using yasm in Windows and Linux!? if it's simple it might be worth it if the optimization is good
i actually can't find any documentation for -O, though! "-o <file>" is for output

apparently yasm is a 'rewrite' of sorts of nasm however, and nasm has documentation for -O:

Using the -O option, you can tell NASM to carry out different levels of optimization. The syntax is:

-O0: No optimization. All operands take their long forms, if a short form is not specified, except conditional jumps. This is intended to match NASM 0.98 behavior.
-O1: Minimal optimization. As above, but immediate operands which will fit in a signed byte are optimized, unless the long form is specified. Conditional jumps default to the long form unless otherwise specified.
-Ox (where x is the actual letter x): Multipass optimization. Minimize branch offsets and signed immediate bytes, overriding size specification unless the strict keyword has been used (see section 3.7). For compatibility with earlier releases, the letter x may also be any number greater than one. This number has no effect on the actual number of passes.

[roc_p2]

Indeed interesting, also because in my yasm help (yasm -h) there is no mention of this switch. However, it exists in nasm, where it is described as "optimize branch offsets". Since yasm is a rewrite of nasm, the switch apparently was also ported. By the way, at the beginning I had tested nasm instead of yasm, and it worked too.