Dwarf 2 Meeting Agenda, June 27, 2000, 10:30am PDT

[Michael Eager <eager at eagercon dot com>]

The next meeting will be at SGI on Tuesday, June 27, 2000, at 10:30am PDT.

Agenda:

	000519.2	Location list for data member
	000531.1	Add DW_AT_pc_ranges attribute
	000531.2	Add DW_AT_entry_pc attribute
	000405.1	Global types section
	000517.2	Line Number Table Is_Stmt

Next meeting:

	(Currently, no open issues have been identified.)
	
I have reorganized the web site as previously discussed.  The priority field
has been eliminated and the status for each proposal has been simplified.  
The proposals are now organized into four classifications:

	Open Proposals 
	New Proposals
	Accepted Proposals
	Withdrawn or Rejected Proposals

The web site has been updated:  http://www.eagercon.com/dwarf/dwarf2std.htm
Please take a look and let me know if there are any errors.

There are a number of issues which are incomplete.  Please take a look at
these and see if they should be withdrawn or if they can be revised into 
complete proposals.  (As a reminder, a proposal should contain a description
of the problem being addressed, relevant text from the standard, specific
changes to the standard which are being proposed, and justification or 
explanation for the change.)

I have received word from OpenGroup (formerly XOpen) that they have no 
claim to any copyright claimed by Unix International.  I am investigating
further whether SCO has any claim to the copyright.  I've been in contact
with IEEE-ISTO about having them publish the standard.  ISTO provides
a number of services, including copy editing, publication, insurance, etc.
There is a fee for this, naturally, which the participants would have to
underwrite.

Finally, as we approach the end of this revision of the Dwarf 2 standard,
I think that there are a couple additional topics which I think that we need 
to discuss in the standard.  

First is a general overview of the Dwarf 2 standard and how the data
is organized.

Second is the permissive nature of the standard, that it does not 
prescribe what a compiler must generate, that there are no defined language 
bindings, and that different debuggers may process the Dwarf 2 data in
significantly different ways and exhibit significantly different behaviors.
(We do discuss vendor extensibility; this is the other half of that coin.)

I think that these two topics would significantly aid understanding and
usability of the standard, and address a number of the questions which have
been raised since the Dwarf 2 standard was released.

The third topic is compatibility.  We have (at least so far) decided that we
did not need to change the version number in the Dwarf 2 output, even when
newly defined specifications are used.   The concern is that a debugger 
which accepted Dwarf 2 would also be able to accept Dwarf 2.1 under most
circumstances, and that changing the version number would unnecessarily
prevent debuggers from accepting Dwarf specifications which they could 
process.  We may want to revisit this decision, but in any case, I think
that there should be a section in the specification which discusses the 
changes and how they affect compatibility.  There may be a way to make the
version number conditional upon use of the extensions incorporated in 
Dwarf 2.1.


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