[Dwarf-discuss] Re: optimized code debugging

[Daniel Berlin]

On Thu, 2005-05-26 at 20:24 -0500, jeff nelson wrote:
> On Thu, 2005-05-26 at 17:01 -0500, Jim Blandy wrote:
> > There are some central points getting lost here.
> 
> Thanks for bringing us back on track.
> 
> > The point made in issue 050222.1 is that the compiler may not be able
> > to tell whether a given address range it's emitting is null or not:
> > the start and end addresses may be changed by the assembler or linker,
> > and become equal.  That is, location list entries with identical start
> > and end addresses may appear without the compiler's knowledge.
> 
> If this is true, then it should follow that it is possible for a
> location list entry to have a start address GREATER than the end address
> (and without the compiler's knowledge).

Theoretically, yes, but i'm not sure any of gcc's (which is the compiler
that does this start same as end stuff right now) targets do anything
that could cause that.

The problem, as the issue notes, is that we drop assembly labels into
the assembly file at appropriate points in the code stream, and refer
back to them in the location lists.   

Sometimes the code in between the points we've marked (we do bother to
at least try to make sure there is code there) isn't actually emitted by
the *target* machinery, because it decides it's not necessary right
before emission, or because it rained last tuesday.  However, as far as
the debug info generation knows, they are different labels at different
instructions, so it happily makes a location list out of them.

We obviously do cursory checks to make sure they aren't the same
location, but there are enough cases where the target decides not to
output code that we can't *easily* do anything about this in the
compiler.

> 
> 
> I suggest the standard say "undefined" for both zero-length and
> negative-length. If specific producer/consumer pairs want to assign a
> particular meaning to either one of those conditions, then they can
> always come to an agreement using a private extension to DWARF.


I should note here that, for whatever it is worth, GCC is (and linux
distributions have been shipping with code that does this, particularly
on x86_64) and will continue to emit location lists with start and end
addresses that may be the same, because it's not something we can really
control as long as we are still just outputting assembly.
--Dan