pyelftools icon indicating copy to clipboard operation
pyelftools copied to clipboard

readelf .txt output is missing information while ARM Compiler .txt output is complete

Open rafma opened this issue 5 years ago • 1 comments

Dear all,

I hope you can help me. I am quite new on the topic.

I am working on an .axf file which was transformed in a text file in order to get the DWARF information. I have done this operation two times: once with a fromelf.exe ARM Compiler (version 5.06 update 6, build 750) file and once, using readelf.py. (pyelftools)

In the .debug_info section of the two text files I target a structure called "MyStructure" which has a DW_AT_type indirect DW_FORM_ref_addr 0x3dc. If I then move to the address 0x3dc, I discover that in the file create by the .exe the information is complete while in the other file something looks missing.


#1 way trough .exe

DW_AT_type indirect DW_FORM_ref2 0xa2 (0x3ae)

With the address 0x3ae I am able to arrive to the basetype...


#2 way trough readelf.py

DW_AT_type : 162

If I go to the address 0x3dc in the readelf.py text the information is not complete


So it looks like there is something missing and unfortunately I am working on create a small code in python which is able to take as an input the name of the structure and the variable and arrive to the base type of it and get some information

Do you know if there is any way of getting this address (0x3ae) which I am missing and is not letting me arrive to the base type?

I have attached the files I have used:

simple. axf is the binary file

simple_dump.txt is the file created by the fromelf.exe

simple_readelf.txt is the file created by the readelf.py

Thank you in advance

simple.txt simple_dump.txt simple_readelf.txt

rafma avatar May 07 '19 17:05 rafma

The ref2 form is relative to the CU (die.cu.cu_offset).

Add 162 to the containing cu.cu_offset of 0x30c = 0x3ae.

I was confused that simple.txt is for a different binary with one CU.

mdmillerii avatar Jan 23 '20 21:01 mdmillerii