CompileUnit._parse_DIEs() misreads DIE size in rare instances

[danharel]

It appears that pyelftools is having trouble correctly parsing the DIEs of all of the Go executables that I've passed it so far.

For reproduction purposes, I've uploaded the object file I was using as well as a python script and shell script that will replicate the issue. Additionally, I've uploaded both the full output from both executions, as well as a trimmed version of each that begin where the issues first appears.

https://drive.google.com/file/d/0B393V_QOoZPjUU5rbkNpV19zREU/view?usp=sharing

One of the first things you'll notice is that the pyelftools output completes long before dwarfdump does. You may also notice that the DIE at offset 0x00016ce8, according to dwarfdump, has a size of 17 bytes, while that same DIE according to pyelftools is 23 bytes. Because pyelftools is reading the wrong number of bytes, it interprets the following DIE incorrectly, which causes the next one to be misinterpreted, and so on. This chain of events continues until it reads the "DIE" at offset 0x16d02 after which it stops. So not only is pyelftools misreading these DIE, but it's also not fully parsing the list.

I'm really not sure what could be causing this. Maybe someone else has some idea?

[mdmillerii]

I can't find the binaries (just a ~40 char command line) on drive, but from the output in #112 its the DW_FORM_ref_addr at 0x10ADD5 that is breaking.

Dan can you confirm this is DWARF v2 and a 64 bit binary?

In V2 DW_FORM_ref_addr was a target address because it was before 64 bit dwarf was defined.

[sevaa]

I think https://github.com/eliben/pyelftools/pull/273 addresses it. I have a repro in the unit test - a DWARFv2 file targeting ARM64, with 64-bit ref_addr.