Support reading in object files for executables on macOS

[jrmuizel]

By default, the linker doesn't include debug info into the resulting executable. It's either left in the .o files or put in a dsym file. In the situation where it's left in the .o files there are OSO stabs entries that give the paths of the .o files. We should read those in as needed to resolve the addresses.

[jrmuizel]

There's some code to do this at https://github.com/mstange/profiler-dwarf-lookup

[philipc]

Do you think it makes sense to add something to the object crate that performs the task of Resolver in that code? I'd probably make it return Vec<(file_name, Vec<Symbol>)> (or a similar iterator) and let the caller figure out which symbols contain the addresses they want.

[jrmuizel]

@mstange

[mstange]

That's a great idea!

[philipc]

@mstange I noticed a couple of differences in how LLVM parses the symbol entries in MachODebugMapParser:

• It uses N_FUN with null names to terminate functions, instead of waiting for the next N_FUN with a name. It looks like using the terminating N_FUN is better because it gives the function size.
• It doesn't handle N_SO. Did you encounter a case where the N_SO handling is required?

[mstange]

Oh, the terminating N_FUN comes with the size! I didn't realize that, that's great!

I did not encounter a case where N_SO handling is required. I think all N_FUN symbols are always between an N_OSO and a terminating N_SO, so we might as well treat the N_OSO as the separator and ignore the section terminator.

One important thing that the current profiler-dwarf-lookup code doesn't handle is OSOs that point to archive files: For example, you can have an OSO symbol with the string /Users/mstange/code/obj-m-opt/toolkit/library/../../js/src/build/libjs_static.a(JSAtom.o). Then you need to load libjs_static.a as a goblin::archive::Archive and extract the member with the name /Users/mstange/code/obj-m-opt/toolkit/library/../../js/src/build/libjs_static.a(JSAtom.o). This probably requires a change to your proposed API in order to be represented properly.

[philipc]

It's either left in the .o files or put in a dsym file. In the situation where it's left in the .o files there are OSO stabs entries that give the paths of the .o files.

I don't know much about macOS, but it appears that the OSO entries are what dsymutil uses. Can you run dsymutil to get a dsym and use that instead? Using the .o files seems like a niche use case.

[jrmuizel]

Running dsymutil is pretty time consuming (see rust-lang/rust#47240) so it's nice to avoid it if at all possible. Further, most tools (lldb, gdb, nm, Instruments, ...) on macOS support using the OSO entries directly without needed a dsym file.

[philipc]

My current thinking is to change object::SymbolMap to also include the object file name. I've done some work to start on that here, but it might be a while before I get to do the corresponding addr2line changes.

[luser]

This got a fully-fleshed-out implementation in the fix-stacks binary:
https://github.com/mozilla/fix-stacks/blob/c30daaef43bd15486fba189b06487aa24dad3492/src/main.rs#L433-L502

[mstange]

object now exposes these references in Object::object_map. That's what I use in profiler-get-symbols: https://github.com/mstange/profiler-get-symbols/blob/3c315ba523e2c876e3de493ba36ef9fc0d01affa/lib/src/macho.rs#L317-L319

[philipc]

backtrace-rs implemented this in rust-lang/backtrace-rs#377. This needs to be handled at a higher level than the addr2line API, so closing this issue.

[mstange]

@jrmuizel Did you file this issue about the addr2line crate API or about the addr2line CLI example in this repo?

[philipc]

Ah sure, that probably isn't too hard to do (rough version at philipc@65f2154). I don't currently have a macOS system to develop on though.

[philipc]

I think https://github.com/mstange/samply/tree/main/wholesym-addr2line supports this, so hoping that is sufficient now.