Re: Dwarf2 Meeting Agenda, January 9, 2001, 10:30pst

[brender at gemevn dot zko dot dec dot com (Ron 603-884-2088)]

>INCOMPLETE PROPOSALS
>====================
>
>We have several incomplete proposals:
>
>	991026.3   Duplicate Dwarf data deletion
>	991108.2   C++ virtual functions
>	991108.13  Unwinding stacks (DW_CFA)
>
>...
>
>All three of these incomplete proposals contain discussion about the
>various areas, but lack specific proposals for changes to the Dwarf
>standard.  Have I missed any updates or replacement proposals?  
>
>Unless I hear additional information relating to these three proposals
>I will list them as rejected by the committee.  

Duplicate Dwarf data deletion (represented here by 991026.3, more recently
addressed in Dave Anderson's email of 14 November 2000 and discussed
at the 30 November meeting, although that is not mentioned in the minutes)
was one of the key reasons that stimulated the formation of this group
and our revision efforts. I find it most unfortunate that we might
"finish" without achieving anything on this topic. I'd like to suggest
that we have some limited amount of brainstorming concerning whether
we really want to give up or whether we should try to have another
run at it. I have some thoughts (obviously not written up) about how
we might better "enable" a vendor solution, without dictating the whole
scheme. I'd like the chance to get feedback on whether it is worth
the effort to try or not.

991108.2 is a bit of a puzzle. The "original" 991108.2 covered several
issues. It was considered at the 8 February meeting with the minutes reporting
that 1) "[Felix] will draft a proposal to add DW_OP_call", which he
did (00217.1 re Dwarf procedures) and we adopted, and 2) "Jason will rewrite
the proposal with only DW_AT_vptr_* specifications". It appears that Jason
did his part too, in his email of 21 February re "991108.2: vtable element
decoding". But I can find no mention of a " formal proposal" numbered
000221.* either being setup or considered. So I think that it is appropriate
for us to consider Jason's mail as being proposal 000221.1, which replaces
991108.2 and is the "completion" proposal we have been "waiting" for.
(At first glance, I think it looks like a reasonable and appropriate proposal
too.)

991108.13 has, I think, been in fact covered by other proposals (namely
001012.1 re factored offsets and 000330.1 re CFA expressions). So this
proposal is properly "rejected" because the problem it sought to address
is solved in other ways.


>LATE PROPOSALS
>==============
>
>A proposal was submitted on Dec 13, 2000, which addresses an issue 
>related to discontiguous scopes or possible defect in the prior 
>proposals on this issue.  This proposal appears to modify or depend
>upon proposal 001101.1 which was rejected, or 001130.1 which is 
>discussed below.

This is a misunderstanding. The Dec 13, 2000 proposal has nothing to do
with discontiguous scopes. It relates purely to location lists (from V2).

>In September, we established a time frame for finalizing the Dwarf 
>standard.  Although we did not establish a firm deadline for submission 
>of proposals, we did establish a target date of Jan 1, 2001, for 
>"All issues resolved and proposals considered".  I believe that this
>proposal (and any others yet to be received) are beyond any reasonable
>date for submissions.

Thanks for telling us ahead of time...


>DISCONTIGUOUS SCOPES
>====================
>
>There have been numerous proposals regarding discontiguous scopes:
>
>	000531.1	Withdrawn
>	000914.1	Accepted
>	001101.1	Rejected 
>	001130.1	No action
>	Dec 13, 2000	Not accepted 
>
>Proposal 001101.1 indicates that there are flaws in 000914.1 as accepted.
> 
>My current reading of this is that we have accepted a flawed proposal, 
>rejected one proposed revision, and have little support for another revision
>(or perhaps two).  At this juncture, I see several choices:
>
>  1) Reconsider 000914.1 and confirm that it is accepted in its current state.
>  2) Reconsider 000914.1 and reject it based on the flaws noted.
>  3) Consider one or more modifications to 000914.1.

As I indicated in 001101.1, the problem in 000914.1 is shared with location
lists (precisely because the approach in 000914.1 was modeled after location
lists before it was recognised that there was a problem there). If the
problem were not shared with location lists, it would be perfectly sensible
to withdraw 000914.1 (hopefully to try again, possibly to abandon altogether).
Since the problem is shared with location lists, I think it behooves us to
try to solve the problem rather than just forget it and move on.

>None of the several proposals represents an effort to standardize current
>practice by any supplier.  We seem to be in a mode of successive modification,
>refinement and correction to an undemonstrated methodology.
>
>My view is that this issue is not ripe and that our acceptance of 000914.1 
>was not adequately considered.  My recommendation is that we reconsider 
>000914.1 and reject it with the recommendation that the submitter 
>implement it as a user extension to Dwarf 2.

If an existing user extension is the criteria, then 000531.1 should have
been accepted because something very, very close to that is in use in the
shipping Compaq compilers and debugger on Alpha Linux using a DWARF vendor
extension. The same concepts are also in shipping code on VMS Alpha and
Tru64 Alpha, although there the representation is necessarily different
because neither uses DWARF.

And if we do reconsider and reject 000914.1, what of the problem in location
lists?

>OTHER ISSUES
>============
>
>Documentation:  plans for document review and public distribution.
>
>Version:  I plan to submit a proposal on version numbering.

I thought you said it was too late to submit proposals?