[Dwarf-discuss] Re: optimized code debugging

[jeff nelson]

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).

> Assigning a special interpretation to such entries, as John is
> suggesting the standard allow, is just as bad as forbidding them:
> either way, you put the compiler in a position where it can't be sure
> how the info it's emitting will be interpreted.
> 
> Currently, the compiler can't tell if it's producing an error; that's
> the problem 050222.1 asks us to fix.  If the standard were to assign a
> meaning to null entries, then the compiler wouldn't be able to tell if
> it was producing an entry with one the special meanings or not.  But
> they're both problems.

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.

-Jeff