Get it working on Mac.

[nnethercote]

There are at least two challenges here.

• Fat binaries can have both 32-bit and 64-bit code in them. This requires using Symbolic's Archive type, which isn't hard.
• Debug info on Mac is normally (always?) stored separately, in a .dSYM folder.

[nnethercote]

This is indeed tricky. Here's what I've learnt so far.

On Linux, debug info is normally stored in the executable/library file, along with the code, which is easy to deal with. Alternatively, the debug info can be stored in a separate file, and fix-stacks currently doesn't handle that. But separate debug info is uncommon, and not used by Firefox.

On Windows, debug info is in a separate PDB file. This PDB file is named in the executable/DLL, and symbolic_debuginfo has a function PeObject::debug_file_name that lets you get that name. So it's pretty easy to get the debug info for a given executable/DLL. (As done in #4.)

On Mac, debug info is in a separate .dSYM directory. E.g. if you compile a single file with clang -g example.c -o example-mac, it creates an executable example-mac and a debug info directory example-mac.dSYM/. The debug info is within the file example-mac.dSYM/Contents/Resources/DWARF/example-mac, which file says is a "Mach-O 64-bit dSYM companion file x86_64".

As far as I can tell, the Mach-O executable/library does not point to its companion dSYM, so there is no obvious way to get from the executable/library to the dSYM. Both the executable and the dSYM do contain a UUID that should match, so once you have a dSYM you can check that it matches the executable.

So, how to find the dSYM for an executable/library? One easy thing is to just look for the dSYM next to the executable/library. That works for the example-mac/example-mac.dSYM/ example above. But it doesn't work for Firefox. In a Firefox build there aren't any dSYMs produced for C++ code. E.g. there is no xul.dSYM. And yet, somehow fix_macosx_stack.py is able to symbolicate addresses from Firefox files such as $OBJDIR/dist/Nightly.app/Contents/MacOS/XUL. It uses atos to do this. I don't know how atos achieves this, and it appears that atos isn't open source so there's no way to find out how it works.

Finally, it's possible to run ./mach buildsymbols which uses dsymutil to build all the dSYMs for Firefox libraries. It puts those dSYMs into some other file and then deletes them. So there's a possibility of requiring that a variant of this command be run before fix-stacks is run, but that's inconvenient, and an inferior workflow to the current one using fix_macosx_stack.py.

[nnethercote]

When I run atos on a simple example-mac/example-mac.dSYM/ pair it gets debug info by looking at the dSYM. I know this because if I remove the dSYM it fails to get the file names & line numbers

When I run atos on a Firefox build it gets debug info by looking at .o files. I know this because if I remove the relevant .o files it fails to get the file names & line numbers. It's a similar story with a simple example-mac.o/example-mac example (with no dSYM); in this case the example-mac.o file must have been compiled with -g.

Other things of note:

• executables/libs do contain the names of the .o files they were built from.
• symbolic_debuginfo doesn't appear to be able to read debug info from .o files on Mac :(

[nnethercote]

Fixed by #10.