DWARF source code line reporting not working about blazesym HOT 10 CLOSED

No problem: I'll just mail you my laptop, and then it'll work for both of us!

from blazesym.

Realized that I was going by the line numbers in your original diff, which at the present moment is in symbolize_gsym, so wasn't testing symbolize_dwarf at all. Same result as you now.

Is this worth focusing on, if we'll use gimli soon?

from blazesym.

Is this issue solved? I tried reproducing, and the assertion succeeds-- it finds that factorial was defined on line 8 of test-stable-addresses.c.

from blazesym.

Is this issue solved? I tried reproducing, and the assertion succeeds-- it finds that factorial was defined on line 8 of test-stable-addresses.c.

Interesting. It still does not work for me. I haven't looked into it more than that, though.

Edit: CI seems to concur that it's not working: https://github.com/d-e-s-o/blazesym/actions/runs/5046482841/jobs/9052058258#step:6:165

from blazesym.

No problem: I'll just mail you my laptop, and then it'll work for both of us!

;-) Could you attach your system's data/test-dwarf.bin, then I could compare binaries? I suspect this will all get addressed once we switch to gimli, which hopefully is not so far out anymore at this point.

from blazesym.

Ah, that explains it. Thanks!

Is this worth focusing on, if we'll use gimli soon?

I was just curious if there was some non-deterministic behavior causing it to work on your system but not mine that I'd have wanted to investigate. But given that as you state it's not working for you either it's probably best to just wait for the gimli conversion.

from blazesym.

The root of the problem is that ElfCacheEntry::new calls DwarfResolver::from_parser_for_addresses with an empty addresses argument:

That function never gets called again, so DwarfResolver::addr_to_dlcu, and thus DwarfResolver::debug_line_cus, is always empty.

from blazesym.

Oh nice, thanks for digging into it! Feel free to open a PR if you have a fix in mind. Otherwise I'll look into it soon.

from blazesym.

So it seem the empty addresses stuff is actually fine: the semantics are that if no addresses are provided, all line information is gathered. The problem is more that we see an invalid extended op code, can't handle it, and then swallow the error (!!!).

invalid extended opcode (ip=0x23, insn_size=0x0)

So yes, this will need to wait until we transition to gimli...

from blazesym.

Ach, you're right. I briefly looked into debugging it, but I've no experience with the DWARF FSM: definitely worth waiting for gimli.

from blazesym.