[Dwarf-discuss] Re: optimized code debugging

Jim Blandy jimb
Tue May 31 20:23:20 PDT 2005


jeff nelson <jeff.nelson at hp.com> writes:
> > 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.

Well, if we do that, then GCC won't be able to tell whether it's
emitting an undefined construct.  If our intent is to accommodate
toolchains like GNU's, it seems to me the spec needs to say that
consumers should ignore location list entries with empty (or
negative-length) address ranges.

But let's take a step back: Dwarf has many clean mechanisms for vendor
extensions: vendor tags, vendor attributes, vendor expression
operators, and so on.  And if you stick to the existing attribute
forms, they're even *forward*-compatible: consumers can skip
information they don't recognize.  Dwarf is superb in this regard.
Vendors should make an effort to use those mechanisms rather than
assigning special interpretations to things like empty/negative
location lists.  They'd serve the purposes I've seen floated in this
thread just fine, as far as I can see.

So I'm in favor of the solution suggested in the original issue:
directing consumers to ignore location list entries with empty or
negative-length address ranges.


(And for what it's worth --- directing consumers to ignore empty-range
location list entries is not just a crutch for GCC; it can support
certain optimizations further down the toolchain, as well.  Some
platforms have linker relaxations that delete instructions altogether,
rather than just replacing them with shorter forms.  On such
platforms, location list entry address ranges could become empty at
link time, even when the compiler and assembler did emit instructions
between the pair of labels cited by the location list entry.)




More information about the Dwarf-Discuss mailing list