[Dwarf-discuss] Re: Dwarf Comment Submission

[Michael Eager]

I think this would be better discussed on the mailing list
rather than as a new issue.

dwarf at eagercon.com wrote:
> Subject: Re: DWARF Issue 041108.1
> Submitter: Phil Barnard
> Email: phil.barnard at atollic.com
> Section: 7.5
> Page: 119
> Type: Clarification - request for clarification about the standard
> Comment: 
> I\'ve read both the v2 and v3 specs but still feel there is some need for clarification on the use of padding (for me anyhow), specifically in the debug_info section.
> 
> sections 7.5.2 and 7.5.3 seem to tell us that a null debugging info entry can be used for padding to suit section alignment requirements.
> However a null die is also used to specify the end of a list of sibling die\'s, and thus, when forming a tree of die\'s, to pop back up a level so that the next die is a sibling of the previous die\'s parent.
> 
> Surely this implies that the only place padding can be inserted is inbetween compilation units (i.e. regions in the debug_info section that are delimited by compilation unit headers) as the header\'s size value can be used to determine the start of the next compilation unit header.
> 
> If padding were to occur anywhere else, surely a stream of null die\'s would result in an incorrectly formed tree of die\'s (and even in this case a special rule would have to be added to the dwarf parser to ignore a stream of null die\'s once you\'ve popped your way back up to the root).
> 
> Also, related to this issue, and the discussion, the standard doesn\'t seem to explicitly allow or disallow the effective die tree structure within a single compilation unit (defined by a compilation unit header) to contain more than one \'root\' DW_TAG_compile_unit (or for that matter any other die as it also doesn\'t explicitly state that the DW_TAG_compile unit must be the first/root entry).  Some guidance, and examples here would be useful.  Using indentation to show parent/child relationships to highlight the issue:
> 
> <cu header #1>  -- a simple compilation unit region
> DW_TAG_compile_unit
>    DW_TAG_typedef
>    DW_TAG_variable
>    DW_TAG_subprogram
>       DW_TAG_formal_parameter
>       DW_TAG_lexical_block
> <cu header #2> -- a rather odd compilation unit region
> DW_TAG_compile_unit
>    DW_TAG_typedef
>    DW_TAG_variable
> DW_TAG_compile_unit
>    DW_TAG_subprogram
>       DW_TAG_formal_parameter
>       DW_TAG_lexical_block
> <cu header #3>
> ...
> 
> I hope that the above makes sense and appreciate your comment.
> 


-- 
Michael Eager	 eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077