As many of you probably know Etnus is working on support for UPC in
our TotalView debugger.

Since there are many different compiler groups producing UPC
compilers, and there is a good chance that more than one UPC compiler
will use DWARF2 debugging format, I would like to propose a standard
set of DWARF2 encodings for UPC specific debug information.

This should

1) minimise the work I have to do, since I'll know how the UPC
   information is represented in DWARF2 by all the compilers.
2) save the compiler groups work, since there will be an existing
   specification to work to, and they won't have to make it up for
3) provide folks who aren't using DWARF2 with a view of the
   information which a UPC enabled debugger will require, so that they
   can more easily add it to whatever debug format they are using.

I did propose this to the DWARF 2.1 committee for formal
standardisation, however their opinion was that

1) It's too late for complex new proposals.
2) They've never heard of UPC and it's "experimental" so shouldn't be
   in the standard. :-(
3) The proposal didn't have backing from multiple compiler groups, so
   they didn't want to standardise something other groups might
   disagree with.

I have therefore withdrawn the proposal from the DWARF2.1
committee. We may collectively want to raise the issue there again
(possibly during their public comment period) if we agree that the
proposal is sensible and see benefit in having it in the formal DWARF
2.1 standard.

Here's the proposal. Note that the specific values for constants used
here are all in the "Vendor extension" ranges of DWARF2, at "random"
values in the hope of avoiding conflicts with existing vendor
extensions; should we wish to submit this to the DWARF 2.1 committee
the values would then change to be in the standard-assigned ranges.



Additional discussion (not part of the proposal)
Any UPC debugger must know about the shared property of types,
therefore that is the key component of the proposal. Support for the
"strict" and "relaxed" qualifiers is less important, since the
debugger is unlikely to be able to enforce these properties in its
accesses to variables. These tags are included for completeness so
that the debugger can correctly show the user the type they have used
when declaring a variable.

The AT_threads_scaled attribute could potentially be removed, provided
that the compiler can generate normal DWARF for a run-time sized
array, referencing some process' variable which contains the value of
"THREADS", or the appropriate array dimension. The problems with this
are that

1) It does not make it easy for the debugger to display the array
   as being declared "[34*THREADS]", rather than as being "[*]"
2) It may not be simple for the compiler to find a variable containing

This attribute is, of course, unnecessary in a "static THREADS"
compilation environment.

Comments, brickbats to me, (and the list) please.

-- Jim