Dwarf 2 Minutes, May 16, 2000

[Michael Eager <eager at eagercon dot com>]

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.
	
-- 
Michael Eager	 Eager Consulting     eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077