Re: PEP TALK -- SPEAK UP!

[David B Anderson <davea at quasar dot engr dot sgi dot com>]

M. Eager writes:
>A standards committee does its best work when validating current practice.  It 
>does its poorest work when it tries to create mechanisms on the fly, 
>with littleinvestigation, based on little more than conjecture, 
>assertion, and hyperbole.  We have done much less of the 
>former than I prefer.  Accordingly, I do not 
>feel that blue sky brainstorming, as you have suggested, is appropriate for 
>the Dwarf standards committee.

It's for this reason that I have not moved forward on
a detailed proposal for compression/duplicate-removal.

I think I have identified the key issue
	"how to find types when the reference is from one CU to another"
and the restriction
	"you cannot use DW_FORM_ref_addr because with separate compilation
		it cannot be depended on to do the right thing".

Yes, Elf section groups (aka COMDAT)
are a step in the right direction, but
they just provide the underpinning for dwarf for some platforms
and don't help with the issue above.

Naming the types is not simple as some may be anonymous or
have no defined 'canonical name' or  have a very long
canonical name (mangled or otherwise).

There is also the choice of 
	1 or 2-level names and
linker involvement in all the names or leaving much to the
debugger to match up.

I have my preferences in these matters, but without
an implementation a proposal seems unwarranted.

So perhaps we should get tough :-)  now and wrap this up.

As I said in my mail yesterday, the document seems to be
in pretty good shape (modulo minor issues).

We could consider reintroducing 'Future Directions'
in the document
and put there a few words about the few things we
know about that we don't explicitly handle, one being
as compression/duplicate-removal/COMDAT.
Not to constrain others, but to encourage implementations
and to encourage implementors to document their approach.

davea@sgi.com