debug_loc decoding error with readelf/objdump ?

[Christian Bruel]

I reduced the case a little bit more, see new attachment.

So basically what seem to happen is that the debug_loc entry is emitted as

.long 0     // .LVL0-.Ltext0
.long 0     // .LVL1-.Ltext0
.word 0     // length
.long 0     // entry terminator
.long 0

So it looks like the objdump implementation takes the first two 0 
addresses as the terminator, and then the other entries are shifted.

The question is is it an implementation restriction or a DWARF2 
restriction ?. Since the location list entry has a length field, the 
terminator shouldn't be necessary, and consequently an entry with 0,0 
addresses could be valid.

Second hypothesis, if the 0,0 terminator is necessary by the 
implementation, could the dwarf2 reader report a warning rather than 
silently emitting a corrupted output ?

Any comment ?

Best Regards

Christian


On 08/31/2010 11:39 AM, Christian Bruel wrote:
> Hello,
>
> When using a DWARF2 debug_loc entry, with 2 relative addresses at 0 and
> with a 0 size, I get a strange "There is a hole" warning message, and
> the entries are not decoded (subsequent ones are corrupted).
>
> for instance, using the attached reduced case from a more complex GCC
> generated DWARF2 : with
>
> as bad.s -o bad.o&&  objdump --dwarf=loc bad.o
>
> I get:
> ------------------------------------------
> Contents of the .debug_loc section:
>
>       Offset   Begin    End      Expression
>       00000000<End of list>
> objdump: Warning: There is a hole [0x8 - 0x13] in .debug_loc section.
>       00000013<End of list>
> -------------------------------------------
>
> Note that the entry is not dumped, I expected to get:
>
> --------------------------------------------
> Contents of the .debug_loc section:
>
>       Offset   Begin    End      Expression
>       00000000 00000000 00000000 (DW_OP_reg4) (start == end)
>       00000000<End of list>
> ---------------------------------------------
>
> Reading the DWARF2 specifications, in chapter 7.7.2 on locations lists,
> I don't see anything that prevents my example to be valid.
>
> Both readelf, dwarfdump report the same warning, but dwarfdump seems to
> be OK with it.
>
> Could this be a bug with readelf and dwarfdump ? Or did I miss something
> from the standard ? (and so would indicate a bug in GCC) ?
>
> many thanks.
>
> Christian
>
>
>
>
>
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bad.s
URL: <https://sourceware.org/pipermail/binutils/attachments/20100831/e5a9c9ff/attachment.ksh>