This is the mail archive of the
dwarf2@corp.sgi.com
mailing list for the dwarf2 project.
Re: Philosophy [was Re: location lists]
- To: Dwarf 2 <dwarf2 at corp dot sgi dot com>, Michael Eager <eager at eagercon dot com>
- Subject: Re: Philosophy [was Re: location lists]
- From: David B Anderson <davea at quasar dot engr dot sgi dot com>
- Date: Fri, 30 Mar 2001 07:54:13 -0800 (PST)
- Reply-To: David B Anderson <davea at quasar dot engr dot sgi dot com>
T. Allen
> If a debugger fails to understand a DW_TAG_local_copy, then the debugger
> behaves as though the compiler failed to describe local copies of any
> global or uplevel-referenced variables. I've found no compiler which
> implemented location lists at all in DWARF (except for one research
> project which didn't address global or uplevel-referenced variables). So,
> this is the current state of affairs. Apparently, no one perceives this
> is all that bad.
M. Eager.
>Quality of implementation refers to how well a particular implementation
>handles the various aspects of Dwarf. The failure to implement a part
>of the Dwarf specification as defined is not a QOI issue, it is a
>lack of conformance. The Dwarf specification does not describe subsets
>or optional TAGs which may or may not be implemented as desired.
>
>The Dwarf specification is descriptive, not prescriptive. It does not
>contain language bindings which require that language features be described
>in any particular fashion. This is a flexibility offered to producers,
>not consumers. A consumer, which claims to accept Dwarf 2, would be
>expected to accept and correctly interpret all of Dwarf 2, not some
>arbitrary subset.
>
>That you have not found any compilers which generate location lists
>is perhaps an argument that these are not necessary in the Dwarf
>specification. In this case, eliminating them from the specification
>would permit consumers to eliminate support this feature. Unless
>this is done, I would expect any consumer which claims to accept
>Dwarf 2 to accept and correctly interpret location lists.
Well, I'm back from vacation, catching up with email.
Trying anyway.
There here is a bit of miscommunication above.
That a *compiler* fails to *emit* location lists is not a QOI issue,
nor a conformance issue.
That some consumer fails to read and understand location lists
is a conformance issue (and, so, is a consumer QOI issue if
some dwarf file contains a location list and the consumer
needs it to report things correctly).
For example, SGI IRIX cc does not emit location lists, so
the lack of correct code in SGI libdwarf to read them
is a conformance issue, but irrelevant from a QOI viewpoint as
no debugger user can tell the support is not yet there in libdwarf.
Regards,
David B. Anderson davea@sgi.com danderson@acm.org http://reality.sgi.com/davea/