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
described.
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.
Approved.