You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If, instead, you change the offset passed to LoadTree to 0x139d02d2 (the start of the compilation unit), the example works properly. Also, by print-debugging, I have checked that the offset that is read for the problematic entry matches the one outputted by llvm-dwarfdump.
Why does this happen
According to this comment in debug/dwarf, Reader.Next() sets the current unit when it passes by a compilation unit DWARF entry, and then uses the offset of the CU to adjust the rnglist offset when encountering one. If Seek() is called directly to an offset that is after the compilation unit DWARF entry, that information is not set and the offset is incorrect.
How to solve this
Probably, by finding the CU for an offset in the first call and then reusing the reader across recursive calls.
The text was updated successfully, but these errors were encountered:
This issue is the root cause of parca-dev/parca#5291.
What's the issue
Calling
godwarf.LoadTree
with certain offsets in certain binaries can result in incorrect DWARF entries being read.How to reproduce
First, download and decompress ClickHouse binary:
Then, compile this:
You will get the following output:
If, instead, you change the offset passed to
LoadTree
to0x139d02d2
(the start of the compilation unit), the example works properly. Also, by print-debugging, I have checked that the offset that is read for the problematic entry matches the one outputted byllvm-dwarfdump
.Why does this happen
According to this comment in
debug/dwarf
,Reader.Next()
sets the current unit when it passes by a compilation unit DWARF entry, and then uses the offset of the CU to adjust the rnglist offset when encountering one. IfSeek()
is called directly to an offset that is after the compilation unit DWARF entry, that information is not set and the offset is incorrect.How to solve this
Probably, by finding the CU for an offset in the first call and then reusing the reader across recursive calls.
The text was updated successfully, but these errors were encountered: