Minutes, June 13, 2000

Discussion --

Line number table

    This was followup to discussion on the email list. Section
    6.2 in the Dwarf 2 spec describes line number information. Some
    comments on the email list questioned the meaning of is_stmt,
    and whether having a default value for it was useful.

    General consensus was that a default value was both reasonable
    and useful. As suggested in the commentary, a simple code generator
    would only emit a single line number entry, which would represent
    the start of a statement. More sophisticated code generators
    (the comment at the top of page 53 mentions "pipeline scheduling
    code generators", which probably would be better described as
    "optimizing code generators") might generate multiple line number
    entries, but only one is identified as the statement boundary, so
    it would have a default of false and use the DW_LNS_negate_stmt
    to set the flag to true on the entry marking the statement boundary.
    There was the suggestion that the word "would" be replaced by
    "might" in the comment at the top of page 53, although it isn't
    obvious that this would clarify anything.

    There was some discussion about what "statement boundary" as used
    in the commentary at the bottom of page 52 actually was intended
    to mean. This could be better expressed as "start of statement",
    or where the debugger would be expected to stop while stepping
    through the program. Whether this is the first instruction emitted
    for a statement, or the instruction which performs an assignment,
    or some other location, is a quality of implementation or style
    issue which should be determined by the compiler writers and
    debugger developers.

    The suggestion, passed on second hand from compiler developers,
    that once the code was generated that there were no statement
    boundaries, was felt to be, at best, unhelpful to people trying
    to debug programs generated by the compiler. The compiler needs
    to identify statement boundaries if there is to be any chance that
    the debugger will be able to step between them.

Global types section

    James Cownie called in from England to offer some explanatory
    comments about proposal 000405.1. This is an optimization for
    looking up class types, similar in intent to the Pubnames
    optimization. There is a representation issue about names generated
    by templates and template functions -- whether the mangled name or a
    canonical version of the user declared name should be used.

    Jim's comments were very helpful and this proposal will be considered
    at a future meeting.

Issue discussion:

000517.1     .debug_pubnames definition

    The description in section 6.1.1 mentions "global objects". This
    usage is probably appropriate from the viewpoint of a linker,
    where everything, whether code or data, is an object. But more
    modern usage has objects only containing data. This proposal
    adds "and functions" to make it clear that both data and code
    are included.

    Approved as an editorial change.

991110.1 Namespaces

    This proposal adds descriptions to Dwarf 2 to describe C++ namespaces.

    There was some discussion about where this should be placed in the
    Dwarf specification. Although there was a suggestion that namespaces
    are really different from other topics, it seems most appropriate to
    include it in Chapter 3, Program Scope Entries, where module is also

    It was noted that this may be an incompatible change. If a debugger
    encounters a Namespace DIE, does not recognize it, and skips over all
    of it's child entries, it may miss definitions for types which are
    referenced by later DIEs. Depending on how the debugger handles these
    references, this may be an incompatible or a benign change.