Minutes, Dwarf 2 meeting, Nov. 9, 1999

The agenda for the meeting was to discuss and clarify the issues which
were mentioned at the Oct. 26 meeting, identify "champions" for each issue,
and encourage committee members to submit written proposals for these
issues.

The following issues list was posted to the email reflector:

Date Prio Status Champion Summary

991007   B I SGI?          Decompose Dwarf2 compilation units
991021   B I Cygnus?      Non-contiguous functions
991026.1 C I ?            Fortran 90 support
991026.2 C I ?            C++ support
991026.3 C I ?            Duplicate Dwarf data deletion
991026.4 C I ?            Java support
991026.5 C I ?            Register overloading
991026.6 C I ?            Optimized code support
991026.7 C I ?            Name demangling
991102   B N D. Anderson  Modify field definitions for 64-bit arch
991108   B I M. Eager     Multiple instruction set support

This list will be updated to include category information.

There were a number of issues posted to the email reflector after this list
was posted. The last issue, as well as the last issue listed above, will
be discussed at the next meeting on November 23.

Please let me know if there are any corrections or clarifications to the
issues discussed below.

Issues
======

Issue 991007 - Decompose Dwarf2 compilation units

    Felix Burton (Diab-SDS) volunteered to be champion for this issue.
    Discussion of this issue appeared to be related to 991026.3 (Duplicate
    Dwarf data deletion). There were comments that it might be possible to
    create dummy compilation units without difficulty. Compilation units
    could also be constructed in the same fashion that C++ static
    initializer routines are built by concatenating similarly named sections
    from different compilation units. Could someone please write a rationale
    for why Compilation Units should be decomposed?

Issue 991026.1 - Fortran 90 support

    This general issue will be decomposed into more specific issues.
    Bevin Brett (Compaq) volunteered to be champion for this issue.

Issue 991026.2 - C++ support

    This general issue will be decomposed into more specific issues.
    Bevin Brett volunteered to champion this issue.

Issue 991026.3 - Duplicate Dwarf data deletion

    Felix Burton volunteered to be champion for this issue.
    Discussion of this issue appears related to parallel ELF ABI proposals.
    Jim Dehnert will post draft of a revised ELF specification which contains
    COMDAT section identification which can be used for merging sections.

    Related to this was an issue raised by Dave Anderson about an ambiguity in
    the description of DW_FORM_ref_addr. This FORM was intended to permit
    references from one compilation unit to another, possibly to permit
    type or other Dwarf descriptions to be placed in library modules. A
    concern was raised that this might require run-time relocation, but it appears
    that this is not likely. After an executable or shared object is linked,
    all DW_FORM_ref_addr references should be resolved as offsets from the start
    of the .debug section. It is not likely that debug sections would be loaded
    into memory in any event. It was also believed that no compiler generates
    DW_FORM_ref_addr attributes.

    Additional discussion emphasized that it was desirable not to place added
    requirements on assemblers or linkers. Extensions to linkers to eliminate
    duplicate data should be a quality of implementation issue, not required
    functionality.

Issue 991026.4 - Java support

    This general issue will be decomposed into more specific issues.
    Jason Merrill (Cygnus) [is this the correct Jason?] volunteered to
    champion this issue.

Issue 991026.5 - Register overloading

    This had been mentioned at the Oct 26 meeting, but no champion was identified.
    It is unclear exactly what the issue is, since Dwarf 2 does address
    registers with different contents at different places in the code.

Issue 991026.6 - Optimized code support

    Bevin Brett volunteered to champion this issue.
    Discussion on this issue concerned about what Dwarf should describe: the
    source or the object code generated from this source. The extent to which
    a debugger wishes to support optimized code is a quality of implementation
    issue. The Dwarf description should not be the limiting factor, so
    extensions which permit (but do not require) debuggers to provide better
    support for optimized code should be identified.

Issue 991026.7 - Name demangling

    Felix Burton volunteered to champion C++/Java name mangling issues. There
    was discussion that Dwarf 2 currently provides mechanisms to clearly
    identify both mangled and source names, but that compilers were not using
    this method. Felix will investigate this and clarify whether extensions are
    needed or whether current practice needs to be modified.

Issue 991102 - Modify field definitions for 64-bit arch

    Dave Anderson (SGI) posted a proposal which was discussed. There appear to
    be two related issues: (1) changes to Dwarf to permit 64-bit addresses and
    (2) support for Dwarf debug files which are greater than 4Gb.

    For (1), it was not clear that any changes were needed, although there were
    places where there were ambiguities in the Dwarf spec which should be
    clarified.

    Support for (2) raises issues of compatibility. This requires all of the
    32-bit offset and length fields be changed to 64-bit. Unless the Dwarf version
    number is changed, it appears that there will be no way that a Dwarf processor
    would be able to distinguish between 32-bit and 64-bit length field.
    It would appear that any debugging file generated with 64-bit offsets would
    contain many bytes of zeros, which to a degree conflicts with an interest
    in compressing Dwarf data. It was also not clear whether or how programs
    consisting of 32-bit offsets and 64-bit offsets could be linked together.