[Dwarf-discuss] Re: Dwarf Comment Submission

[Chris Quenelle]

I believe the intention is that multiple top-level tags can
be in one CU-block.   The spec uses the same name for
CU tags and for the CU block with a header.
That makes it difficult to even *discuss* what the standard
is trying to say.  :-(

That's the gist of what I was trying to get at with issue: 030814.1

We are working on the terminology issue, but for now I think
you should assume that multiple top-level (CU) tags can be
in a CU block.  (If I'm wrong, someone will correct me I'm sure.)

Also, I don't think that top-level tags are required to be grouped
in any way, and I don't think that one object file is restricted
to containing only one CU block.  So my reading is that an
implementation may choose to split each CU tag into its own
CU block, or it can choose to combine them together.

--chris



Michael Eager wrote:
> 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.
>>
> 
>