search

eliben / pyelftools

Parsing ELF and DWARF in Python
Other
2.04k stars 513 forks source link

Potential Bug in pyelftools (DW_AT_type decoding) #44

Open bshaffer82 opened 10 years ago

bshaffer82 commented 10 years ago

I'm using pyelftools to decode an elf file from the XC32 complier from microchip. My main goal is to decode variables into address so I can peak and poke them over a CAN interface.

What I found is that the DW_AT_type is not correctly being returned in some cases.

I've created files which I'll describe here (this very narrow window makes the formatting horrendous)

Good_decode.txt - shows what I want the program to do. It finds a variable and then iterates over and over until it gets to a DIE that doesn't have a DW_AT_type. It should always find at least one type that describes a variable.

Bad_decode.txt - shows two entries from my python script that is calling the pyelftools. In these two cases the DW_AT_type is not correct.

objdump.txt - shows the output of the XC32-objdump -w tool. Its a big file but if you search for 1c7d you'll find the first die for "adc_raw_data" and if you search for 1c8f you'll find the one for "adc_sensors_ready".

compare.txt - shows just the 1c7d "adc_raw_data" above and below for comparison. As you can see the only difference is in the DW_AT_type field and you can see that they disagree about the address for DW_AT_type. 0x18e9 = 6377 != 5874

Files are located here: https://gist.github.com/bshaffer82/35f6e35be1157fc1776c#file-bad_decode-txt Thanks

eliben commented 10 years ago

Pull requests welcome!

TNThieding commented 5 years ago

I'm observing similar behavior where the value of DW_AT_type is not correct in some cases. Has anyone looked into the root-cause this issue yet?

mdmillerii commented 4 years ago

You need to take the form of the ref into account. If its not of form DW_FORM_refaddr, you need to add cu['cu_offset'] to it.