Many addresses are missing file + line information

[mstange]

When using addr2line to find file and line information from a local Firefox build on macOS, many addresses end up without file or line information. Here's one example:

1. Download nsEmbedFunctions.o.
2. Look up addresses 0x104d and 0x1052.

Result:

cargo run --release --example addr2line -- -C -f -i --exe /Users/mstange/code/obj-m-opt/toolkit/xre/nsEmbedFunctions.o 0x104d 0x1052
    Finished release [optimized + debuginfo] target(s) in 0.18s
     Running `target/release/examples/addr2line -C -f -i --exe /Users/mstange/code/obj-m-opt/toolkit/xre/nsEmbedFunctions.o 0x104d 0x1052`
XRE_InitChildProcess(int, char**, XREChildData const*)
??:?
XRE_InitChildProcess(int, char**, XREChildData const*)
??:?

lldb finds file + line + column information for these addresses correctly: nsEmbedFunctions.cpp:740:34.

(Edit: unnecessary details elided, see next comment for atos getting it right)

[mstange]

More importantly, atos also finds the information:

atos -o /Users/mstange/code/obj-m-opt/toolkit/xre/nsEmbedFunctions.o 0x104d 0x1051 0x1052
XRE_InitChildProcess(int, char**, XREChildData const*) (in nsEmbedFunctions.o) (nsEmbedFunctions.cpp:740)
XRE_InitChildProcess(int, char**, XREChildData const*) (in nsEmbedFunctions.o) (nsEmbedFunctions.cpp:740)
XRE_InitChildProcess(int, char**, XREChildData const*) (in nsEmbedFunctions.o) (nsEmbedFunctions.cpp:744)

[philipc]

Does this only occur for object files? We don't currently process relocations.

[mstange]

Ah, yes, it's likely that this only happens for object files.
If I run dsymutil (which takes 3.5 minutes) and look up the corresponding address in XUL.dSYM, addr2line does find the correct filename + line information.

How hard would it be to add support for object files?

[philipc]

The dwarfdump example in gimli can handle them, so not hard to do in the addr2line example. I assume you want this in a library you can use too though?

[philipc]

We'll want to implement this for split debuginfo support in backtrace-rs too.

[mstange]

Not sure I completely understand the question, but I'd want addr2line::Context::find_frames to find this information in object files. Here's where I'm calling it.

(And I have homegrown split debuginfo code here which I'd love to replace with something from object.)

[philipc]

find_frames will work as long as the Reader supports relocations. You're currently using EndianSlice, which can't handle relocations. dwarfdump has its own Reader implementation, so that will need to be put in a library somewhere. It relies on object though, and gimli has tried to remain independent of object.

Thanks for the split debuginfo link, I plan to add that to object soon. I'm also aware of an implementation in https://github.com/mozilla/fix-stacks

[mstange]

Ooohh, I see. Thanks for the pointers!

[mstange]

I think I have everything I need then.

[mstange]

The problem doesn't seem to be related to relocations. If I comment out the call to add_relocations in the dwarfdump example, it still finds the lines.

And cargo run --release --example simple_line -- /Users/mstange/code/obj-m-opt/toolkit/xre/nsEmbedFunctions.o also works, and from what I can tell the simple_line example doesn't seem to handle relocations:

...
104a /Users/mstange/code/mozilla/toolkit/xre/nsEmbedFunctions.cpp:740:34
1052 /Users/mstange/code/mozilla/toolkit/xre/nsEmbedFunctions.cpp:744:16
...

I'm looking into it some more.

[mstange]

It's because of this check:

addr2line/src/lib.rs

Line 478 in a8757e5

if start != 0 {

The first line row starts at address 0 in this object. This check makes us ignore all the rows.

[philipc]

Ah right. So I'm pretty sure we need that check for executables, because I think the linker leaves the address at 0 for functions that are omitted, instead of deleting the line information (and same for DIEs). So maybe we need to set a flag on Context to say whether it is an object or executable file.

[philipc]

That check was added based on the investigation I did in #67 (comment).

This was when we were still using an interval tree, and so doing a lookup of 0 resulting in poor behaviour. It might be safe to delete the check now. I'll look into it a bit more.

[philipc]

Deleting the 0 check looks okay and matches other tools. I'll do a PR for that once #178 is merged.

[mstange]

Awesome, thank you!