Philosophy [was Re: location lists]

[Michael Eager <eager at eagercon dot com>]

This apparently didn't get through the mailer.

-------- Original Message --------
Subject: Re: location lists
Date: Mon, 19 Mar 2001 08:31:12 -0800
From: Michael Eager <eager@eagercon.com>
To: Todd Allen <todd.allen@ccur.com>
CC: dwarf2 <dwarf2@corp.sgi.com>
References: <200103162312.f2GNCXw01269@toad.ccur.com>

You raise two issues, one technical, one philosophical.  I'll respond in
two emails.  This second one about your philosophical comments.

Todd Allen wrote:

> > >    Is a nice simple extension so bad, compared to this?
> >
> > I believe that I heard this same argument when I was on the C++ standards
> > committee.  Unneeded extensions are bad, since they require everyone to
> > implement them, even in the cases when they are unlikely to be used.
> >
> 
>    Actually, I disagree about everyone needing to implement this extension.
>    Whether or not they do is a quality of implementation issue, itself.
> 
>    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.


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.  

The behavior you describe above for DW_TAG_local_copy is the behavior
which is explicitly provided for vendor extensions to the Dwarf
specification.  See section 7.1.  

-- 
Michael Eager	 Eager Consulting     eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077