GCC 8.2.0 Compatibility

[mnhol]

Hello,

I have been utilizing pyelftools (0.24) to analyze the dwarf symbols of executables compiled with gcc 4.9.2. As of right now I am testing stepping up to gcc 8.2.0 but am running into an "expected 4, found 0" error when parsing the data. Looking at the objdump files that are attached, it seems the 8.2.0 version of the object file has some extra entries with Abrev Number: 0 that are throwing pyelftools off.

Both of the files were compiled with the following command: gcc -m32 -gdwarf-2 -c -x c++ -fno-eliminate-unused-debug-types example.hpp

On the python end I am utilizing: ELFFile.get_dwarf_info() to access the dwarf data.

Are there any known limitations to which gcc versions pyeftools supports? Is there a workaround or something I am missing?

dump_4.9.2.txt dump_8.2.0.txt

[eliben]

gcc versions occasionally tweak their output and it's hard to guarantee pyelftools will work with versions it hasn't been tested with.

PRs welcome to fix this

[mnhol]

@eliben Thanks for the quick response! In the meantime, is there a place where I could find a list of the gcc versions that pyelftools has been tested with?

[eliben]

@mnhol I don't think so. It's fairly widely used so there's no reliable way to find that information.

[sevaa]

A sample problematic binary would be nice to have.

[mnhol]

I am no longer working on this particular project and don't have the proper setup to reproduce at the moment. The example.hpp was just an int variable within a typedef struct. If you have a linux environment with GCC 8.2.0 installed and compile with the options in the original post you may be able to reproduce the issue. HTH

[mdmillerii]

Looking at the objdump files that are attached, it seems the 8.2.0 version of the object file has some extra entries with Abrev Number: 0 that are throwing pyelftools off.

No, those Abbrev: 0 entries are the nesting terminators. You are using a different version of objdump that formats the data slightly differently (the new one includes it). The difference in the supplied output is the addition of AT_decl_collumn attributes, but there is other whitespace differences in the dump in addition to the Abbrev Offset in the CU header being printed in hex.

Without a failing binary I doubt anyone can fix this. There were some fixes for DWARF2 parsing of 64 bit binaries, not sure if that could be the real problem you encountered.