Re: debug_loc decoding error with readelf/objdump ?

[Christian Bruel <christian dot bruel at st dot com>]

On 08/31/2010 09:31 PM, Richard Henderson wrote:
> On 08/31/2010 05:55 AM, Christian Bruel wrote:
> > > The problem is, I think, with gcc, though I've not yet figured out
> > > why (my knowledge of gcc internals is still pretty weak) but
> > > looking at at gcc/dwarf2out.c in the gcc source, in
> > > output_loc_list( ... ) there is code that looks like this:
> >
> > I think this happened when code is optimized after the dwarf2
> > emission (there are places where this can happen: relaxation, ...).
> > I'll go back to look at GCC to see where this occurred.
>
> It shouldn't be able to happen within gcc itself, as dwarf2 is
> emitted last, alongside assembly output.
>
> Relaxation within the linker is a possibility though.  There are
> lots of tables that have to be updated in order to delete insns,
> and I doubt we get them all right.
>
> That said, the only targets with which I have experience with
> relaxation never try to actually delete insns; they only zap
> the insns into nops.  Which is much much easier.

Actually, the code in GCC

/* Don't output an entry that starts and ends at the same address. */
   if (strcmp (curr->begin, curr->end) == 0)
     continue;

looks at the symbols, not their values, that are only known after the 
assembler has resolved the relocation for the local labels.

So the compiler doesn't have a lot of room to decide if the distance 
between the labels is null at this stage of the DWARF2 emission, this is 
why it keeps emitting the Location entries for :

.Ltext0:
foo:	
.LVL0:
.LVL1:
     instr 3

section	.debug_loc
.LLST1:
	.long	.LVL0-.Ltext0
	.long	.LVL1-.Ltext0

It is not only related to the relaxation, I gave that only as an example 
of possible post dwarf2 optimization (which is tough to maintain in the 
target parts indeed).

We concluded that this is not a bug with the binutils, for which the 0 
address is a defined as the entry delimiter. So using it for a 0 address 
range confuses the parsing of other location entries, Maybe as as 
improvement this could be detected in the DWARF2 readers (a "no entry" 
range would be a 0 range"), but it's better to fix my producer.

many thanks

Christian


>