[Dwarf-discuss] Re: optimized code debugging
Thu May 26 21:24:25 PDT 2005
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.
More information about the Dwarf-Discuss