[Dwarf-discuss] Re: Dwarf Comment Submission

[Nettleton, Brian]

The point I'm about to make is a current implementation issue and not
really a standards issue, but implementations are ultimately important
too.

We currently make the assumption in our debugger that the first tag in a
compilation unit block is the only top-level tag.  For the four compiler
implementations we've seen so far this assumption has held.  This was
done for performance reasons.  None of the compilers generate a
DW_AT_sibling attribute for this single top-level tag which makes sense
since they don't have a sibling.  However this situation makes it
relatively expensive to check whether a sibling exists or not--you have
to traverse the children to determine whether a sibling exists or not.
This is expensive enough and never fruitful so that we eliminated it.
We did relax the assumption a bit, just in case, to handle the case
where the top-level tag did have a DW_AT_sibling (but this situation
hasn't been used yet).

-Brian Nettleton
Wind River Systems

> -----Original Message-----
> From: dwarf-discuss-bounces at base3.freestandards.org 
> [mailto:dwarf-discuss-bounces at base3.freestandards.org] On 
> Behalf Of Chris Quenelle
> Sent: Saturday, May 28, 2005 2:40 PM
> To: dwarf-discuss at base3.freestandards.org
> Subject: Re: [Dwarf-discuss] Re: Dwarf Comment Submission
> 
> 
> 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.
> >>
> > 
> > 
> 
> 
> _______________________________________________
> Dwarf-discuss mailing list
> Dwarf-discuss at mail.freestandards.org
> http://mail.freestandards.org/mailman/listinfo/dwarf-discuss
>