From marcelm  Tue Dec 19 10:35:49 2006
From: marcelm (Marcel Mettes)
Date: Tue, 19 Dec 2006 11:35:49 +0100
Subject: [Dwarf-discuss] null entry after DW_TAG_compile_unit?
Message-ID: <4587C085.7070601@altium.nl>

Hello,

I have question about a small detail. It concerns the termination of DIE 
sibling chains at the highest level of a compilation unit.
For one compilation unit, DWARF 3, paragraph 7.5, states:

    Each such contribution consists of a compilation unit header (see
    Section 7.5.1) followed by a single DW_TAG_compile_unit or
    DW_TAG_partial_unit debugging information entry, together with its
    children.

So only one TAG should appear at the highest level.

In all objects I have seen so far this is the case, and no null entry 
follows the DW_TAG_compile_unit. This seems correct because the standard 
specifies only one entry can occur and a null entry counts for one as well.

When writing a parser, the top level looks to have the same form as 
child-DIE-chains. So when parsing using recursive descend, one would 
expect the top-tag-chain to be zero terminated to signal the end of the 
tags.

The question now is, is it valid to have a null entry following that 
DW_TAG_compile_unit? Or is that in violation with the debug format 
specification?

Best regards,
Marcel Mettes.




From ron.brender  Tue Dec 19 13:10:20 2006
From: ron.brender (Ron Brender)
Date: Tue, 19 Dec 2006 08:10:20 -0500
Subject: [Dwarf-discuss] null entry after DW_TAG_compile_unit?
In-Reply-To: <4587C085.7070601@altium.nl>
References: <4587C085.7070601@altium.nl>
Message-ID: <4587E4BC.3050109@charter.net>

Marcel,

Is it valid to have a null entry following a DW_TAG_compile_unit? 
Perhaps, but I think it was certainly not the intent. I recall tweaking 
the language you reference to make clear(er) that there could not be a 
sibling chain of multiple DW_TAG_compile_unit DIEs, but I don't recall 
discussing your particular point.

One piece of evidence comes from noting that Appendix A does not list 
DW_AT_sibling among the "normal" attributes for a compile unit. This 
Appendix is not controlling, of course, but it does suggest intent that 
there not be a following null entry.

OTOH, one could argue I suppose that it would be an allowed extension 
for a producer to waste a byte by throwing in an extra null entry. Or 
even that one or more nulls might be included as padding rather than as 
"real data".

If it is a touch easier for a parser to share a parse state with other 
DIEs-that-allow-siblings, then it seems harmless enough. But my 
inclination is that not allowing this (treating it as an error) is better.

Ron

--------------------
Marcel Mettes wrote:
> Hello,
> 
> I have question about a small detail. It concerns the termination of DIE 
> sibling chains at the highest level of a compilation unit.
> For one compilation unit, DWARF 3, paragraph 7.5, states:
> 
>     Each such contribution consists of a compilation unit header (see
>     Section 7.5.1) followed by a single DW_TAG_compile_unit or
>     DW_TAG_partial_unit debugging information entry, together with its
>     children.
> 
> So only one TAG should appear at the highest level.
> 
> In all objects I have seen so far this is the case, and no null entry 
> follows the DW_TAG_compile_unit. This seems correct because the standard 
> specifies only one entry can occur and a null entry counts for one as well.
> 
> When writing a parser, the top level looks to have the same form as 
> child-DIE-chains. So when parsing using recursive descend, one would 
> expect the top-tag-chain to be zero terminated to signal the end of the 
> tags.
> 
> The question now is, is it valid to have a null entry following that 
> DW_TAG_compile_unit? Or is that in violation with the debug format 
> specification?
> 
> Best regards,
> Marcel Mettes.
> 
> _______________________________________________
> Dwarf-discuss mailing list
> Dwarf-discuss at lists.freestandards.org
> http://lists.freestandards.org/mailman/listinfo/dwarf-discuss





From marcelm  Thu Dec 21 11:07:02 2006
From: marcelm (Marcel Mettes)
Date: Thu, 21 Dec 2006 12:07:02 +0100
Subject: [Dwarf-discuss] DW_AT_namelist_item and DW_AT_bit_stride
Message-ID: <458A6AD6.4000904@altium.nl>

Hello,

Thanks for your help on understanding the piece operator. It has made 
implementing it in the debugger easier.

I may have found two inconsistencies within the DWARF document.

   1. The DW_AT_namelist_item is a DIE reference according to the text,
      yet in figure 0 of the DWARF 3-2005 document is is classified as a
      block-class attribute. Since this is not for the C/C++ language, I
      have no compiler that produces this.

   2. The DW_AT_bit_stride attribute is specified to be one of the
      block+constant+reference types in 2.19 of the DWARF3-2005
      document. In figure 20 is classified to be only a constant.


Sincerely,
Marcel Mettes.




From marcelm  Thu Dec 21 11:07:57 2006
From: marcelm (Marcel Mettes)
Date: Thu, 21 Dec 2006 12:07:57 +0100
Subject: [Dwarf-discuss] tag nesting question
Message-ID: <458A6B0D.8040603@altium.nl>

Hello,

I have been wondering about the rules of nesting tags within tags. I 
have noticed that the dwarfdump tool reports constructs like:

   1. The GNU C++ compiler nests DW_TAG_subprogram inside
      DW_TAG_structure_type for class member functions.

   2. The TASKING compiler nests type TAGS like DW_TAG_base_type,
      DW_TAG_pointer_type, DW_TAG_union_type or DW_TAG_const_type within
      DW_TAG_structure_type when used by one of the struct's fields.

Since the dwarfdump tool check reports these, should I worry or are 
these constructs well within the DWARF specification?

Have a good one,
Marcel Mettes.




From davea42  Thu Dec 21 15:58:36 2006
From: davea42 (David Anderson)
Date: Thu, 21 Dec 2006 07:58:36 -0800
Subject: [Dwarf-discuss] DW_AT_namelist_item and DW_AT_bit_stride
In-Reply-To: <458A6AD6.4000904@altium.nl>
References: <458A6AD6.4000904@altium.nl>
Message-ID: <458AAF2C.8000306@earthlink.net>

Marcel Mettes wrote:
> Hello,
>
> Thanks for your help on understanding the piece operator. It has made 
> implementing it in the debugger easier.
>
> I may have found two inconsistencies within the DWARF document.
>
>    1. The DW_AT_namelist_item is a DIE reference according to the text,
>       yet in figure 0 of the DWARF 3-2005 document is is classified as a
>       block-class attribute. Since this is not for the C/C++ language, I
>       have no compiler that produces this.
>   
Looks me like you've found a bug.
Page 136 is wrong, DW_AT_namelist_item is  a reference as specified on 
page 62.


>    2. The DW_AT_bit_stride attribute is specified to be one of the
>       block+constant+reference types in 2.19 of the DWARF3-2005
>       document. In figure 20 is classified to be only a constant.
>
>   

I agree. Looks like another bug, exactly as you say: page 135 seems
wrong.

Thanks for noticing.
David Anderson




From davea42  Thu Dec 21 16:27:05 2006
From: davea42 (David Anderson)
Date: Thu, 21 Dec 2006 08:27:05 -0800
Subject: [Dwarf-discuss] tag nesting question
In-Reply-To: <458A6B0D.8040603@altium.nl>
References: <458A6B0D.8040603@altium.nl>
Message-ID: <458AB5D9.20704@earthlink.net>

Marcel Mettes wrote:
> Hello,
>
> I have been wondering about the rules of nesting tags within tags. I 
> have noticed that the dwarfdump tool reports constructs like:
>
>    1. The GNU C++ compiler nests DW_TAG_subprogram inside
>       DW_TAG_structure_type for class member functions.
>
>    2. The TASKING compiler nests type TAGS like DW_TAG_base_type,
>       DW_TAG_pointer_type, DW_TAG_union_type or DW_TAG_const_type within
>       DW_TAG_structure_type when used by one of the struct's fields.
>
> Since the dwarfdump tool check reports these, should I worry or are 
> these constructs well within the DWARF specification?
>   
These represent omissions from the dwarfdump
tag_tree.list  file.

In other words, dwarfdump is wrong to warn.

Since I've left SGI future modifications will be coming from me,
not SGI (it is open source and SGI knows I intend to support
dwarfdump/libdwarf and SGI has no problem with me doing this).
I'm going to build a subversion source tree to track changes, but
won't export the tree (sorry), I will just continue issuing updated source.

I'm afraid the *.list files for checking are not very up to date.
I welcome suggestions for improvement (such as the one in this note).
(Thanks Marcel). 

DavidAnderson




From Chris.Quenelle  Thu Dec 21 18:58:22 2006
From: Chris.Quenelle (Chris Quenelle)
Date: Thu, 21 Dec 2006 10:58:22 -0800
Subject: [Dwarf-discuss] tag nesting question
In-Reply-To: <458A6B0D.8040603@altium.nl>
References: <458A6B0D.8040603@altium.nl>
Message-ID: <458AD94E.2030704@Sun.COM>

My understanding (assumption?) is that type nodes should
normally appear inside the scope level where they are visible.
So types defined inside a class should appear as tags inside
the tag that represents the class.

I think it's a little odd that g++ uses DW_TAG_structure to
represent classes instead of DW_TAG_class.  I know they
are basically equivalent in C++, but it would be nice to
say that only DW_TAG_class could contain DW_TAG_member.

FWIW:
I've been working on converting dwarf to XML with the intention
of being able to use XML schemas to do the consistency checking
(then you could easily have different sub-schemas for different
compilers)

Some examples of my experiments are here:
http://blogs.sun.com/quenelle/entry/dwarf_and_xml


Marcel Mettes wrote:
> Hello,
> 
> I have been wondering about the rules of nesting tags within tags. I 
> have noticed that the dwarfdump tool reports constructs like:
> 
>    1. The GNU C++ compiler nests DW_TAG_subprogram inside
>       DW_TAG_structure_type for class member functions.
> 
>    2. The TASKING compiler nests type TAGS like DW_TAG_base_type,
>       DW_TAG_pointer_type, DW_TAG_union_type or DW_TAG_const_type within
>       DW_TAG_structure_type when used by one of the struct's fields.
> 
> Since the dwarfdump tool check reports these, should I worry or are 
> these constructs well within the DWARF specification?
> 
> Have a good one,
> Marcel Mettes.
> 
> _______________________________________________
> Dwarf-discuss mailing list
> Dwarf-discuss at lists.freestandards.org
> http://lists.freestandards.org/mailman/listinfo/dwarf-discuss




From eager  Thu Dec 21 19:27:45 2006
From: eager (Michael Eager)
Date: Thu, 21 Dec 2006 11:27:45 -0800
Subject: [Dwarf-discuss] tag nesting question
In-Reply-To: <458AD94E.2030704@Sun.COM>
References: <458A6B0D.8040603@altium.nl> <458AD94E.2030704@Sun.COM>
Message-ID: <458AE031.7070608@eagercon.com>

Chris Quenelle wrote:

> I think it's a little odd that g++ uses DW_TAG_structure to
> represent classes instead of DW_TAG_class.  I know they
> are basically equivalent in C++, but it would be nice to
> say that only DW_TAG_class could contain DW_TAG_member.

DW_TAG_structure, DW_TAG_class, and DW_TAG_union are all
essentially identical.  It might be reasonable to deprecate
the latter two TAGS.

> FWIW:
> I've been working on converting dwarf to XML with the intention
> of being able to use XML schemas to do the consistency checking
> (then you could easily have different sub-schemas for different
> compilers)
> 
> Some examples of my experiments are here:
> http://blogs.sun.com/quenelle/entry/dwarf_and_xml

Interesting.  A consistency checker would be a great tool.

(Let's not look at converting DWARF to XML.  :-)
Even with about 300Gb, I still run out of disk space.)

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




From dberlin  Thu Dec 21 20:21:48 2006
From: dberlin (Daniel Berlin)
Date: Thu, 21 Dec 2006 15:21:48 -0500
Subject: [Dwarf-discuss] tag nesting question
In-Reply-To: <458AE031.7070608@eagercon.com>
References: <458A6B0D.8040603@altium.nl> <458AD94E.2030704@Sun.COM>
	<458AE031.7070608@eagercon.com>
Message-ID: <4aca3dc20612211221i164018d6u10b93b4fa168b64a@mail.gmail.com>

On 12/21/06, Michael Eager <eager at eagercon.com> wrote:
> Chris Quenelle wrote:
>
> > I think it's a little odd that g++ uses DW_TAG_structure to
> > represent classes instead of DW_TAG_class.  I know they
> > are basically equivalent in C++, but it would be nice to
> > say that only DW_TAG_class could contain DW_TAG_member.
>
> DW_TAG_structure, DW_TAG_class, and DW_TAG_union are all
> essentially identical.  It might be reasonable to deprecate
> the latter two TAGS.

In the specific case of GCC, we'd either have to have a callback to
the C++ FE at debug info output to ask it whether it's struct/class,
or waste a bit in the type structure to store this info.

I posted a patch about 3 years ago that wasted a bit.
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7081
and
http://gcc.gnu.org/ml/gcc-patches/2003-06/msg01748.html

I never got back to updating it in response to the comments, even
though they were very minor, as i started law school back up again
soon after.

If you really feel like it, you could update this patch and resubmit it.

Nowadays, I think it's a waste of time to differentiate the two :)




From Chris.Quenelle  Thu Dec 21 21:25:48 2006
From: Chris.Quenelle (Chris Quenelle)
Date: Thu, 21 Dec 2006 13:25:48 -0800
Subject: [Dwarf-discuss] tag nesting question
In-Reply-To: <458AE031.7070608@eagercon.com>
References: <458A6B0D.8040603@altium.nl> <458AD94E.2030704@Sun.COM>
	<458AE031.7070608@eagercon.com>
Message-ID: <458AFBDC.3040408@Sun.COM>


> (Let's not look at converting DWARF to XML.  :-)
> Even with about 300Gb, I still run out of disk space.)

For now, it's just an interchange format.  I understand the size
issues.  For me, the main size issue that I run into is
for duplicate type information in multiple object files.
XML might make it easier to write filtering and sifting
applications to extract and compress type information. As
a post-processing step, at least.

--chris




From marcelm  Fri Dec 22 11:02:35 2006
From: marcelm (Marcel Mettes)
Date: Fri, 22 Dec 2006 12:02:35 +0100
Subject: [Dwarf-discuss] tag nesting question
In-Reply-To: <4aca3dc20612211221i164018d6u10b93b4fa168b64a@mail.gmail.com>
References: <458A6B0D.8040603@altium.nl> <458AD94E.2030704@Sun.COM>	
	<458AE031.7070608@eagercon.com>
	<4aca3dc20612211221i164018d6u10b93b4fa168b64a@mail.gmail.com>
Message-ID: <458BBB4B.8050608@altium.nl>


> In the specific case of GCC, we'd either have to have a callback to
> the C++ FE at debug info output to ask it whether it's struct/class,
> or waste a bit in the type structure to store this info.
>
> I posted a patch about 3 years ago that wasted a bit.
> See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7081
> and
> http://gcc.gnu.org/ml/gcc-patches/2003-06/msg01748.html
>
> I never got back to updating it in response to the comments, even
> though they were very minor, as i started law school back up again
> soon after.
>
> If you really feel like it, you could update this patch and resubmit it.
>
> Nowadays, I think it's a waste of time to differentiate the two :)
>
>
As being someone who works on debuggers, I would love to see the extra info.
One of my personal goals for the debugger is that it shows exactly what 
was present in the original source code that was compiled, so that 
someone who is debugging may spot an error because of the actual input. 
Hiding differences like struct versus class is not likely to hide bugs, 
but in general I prefer as much detail as possible.

Also, with g++ compiled objects, the debugger must first use some test 
to detect how to display DW_TAG_struct_type (personally I do not want to 
see struct when debugging C++) which I do not like much myself. I would 
like to use as little heuristics as possible, there is enough confusion 
already :-).




From martin  Fri Dec 22 13:23:41 2006
From: martin (Martin Day)
Date: Fri, 22 Dec 2006 13:23:41 -0000
Subject: [Dwarf-discuss] tag nesting question
In-Reply-To: <458BBB4B.8050608@altium.nl>
Message-ID: <003c01c725cc$6933ff80$0202fea9@domain.snsys.com>

> -----Original Message-----
> From: dwarf-discuss-bounces at lists.freestandards.org 
> [mailto:dwarf-discuss-bounces at lists.freestandards.org] On 
> Behalf Of Marcel Mettes
> 
> 
> > In the specific case of GCC, we'd either have to have a callback to 
> > the C++ FE at debug info output to ask it whether it's 
> struct/class, 
> > or waste a bit in the type structure to store this info.
> >
> > I posted a patch about 3 years ago that wasted a bit.
> > See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7081
> > and
> > http://gcc.gnu.org/ml/gcc-patches/2003-06/msg01748.html
> >
> > I never got back to updating it in response to the comments, even 
> > though they were very minor, as i started law school back up again 
> > soon after.
> >
> > If you really feel like it, you could update this patch and 
> resubmit 
> > it.
> >
> > Nowadays, I think it's a waste of time to differentiate the two :)
> >
> >
> As being someone who works on debuggers, I would love to see 
> the extra info. One of my personal goals for the debugger is 
> that it shows exactly what 
> was present in the original source code that was compiled, so that 
> someone who is debugging may spot an error because of the 
> actual input. 
> Hiding differences like struct versus class is not likely to 
> hide bugs, 
> but in general I prefer as much detail as possible.
> 
> Also, with g++ compiled objects, the debugger must first use 
> some test 
> to detect how to display DW_TAG_struct_type (personally I do 
> not want to 
> see struct when debugging C++) which I do not like much 
> myself. I would 
> like to use as little heuristics as possible, there is enough 
> confusion 
> already :-).

I agree. I would  much prefer our debuggers to be able to show the type as
"class x" or "struct x" as appropriate. Currently, for gcc built debug info,
we have to take a guess.

It also makes sense to only accept the correct kind of tag when evaluating a
type cast expression. e.g. only accept "(struct x*) 0x1000" when x is a
struct and not "(class x*) 0x1000".

Martin




From davea42  Fri Dec 22 17:14:55 2006
From: davea42 (David Anderson)
Date: Fri, 22 Dec 2006 09:14:55 -0800
Subject: [Dwarf-discuss] tag nesting question
Message-ID: <458C128F.6050606@earthlink.net>

Martin Day writes:

>I agree. I would  much prefer our debuggers to be able to show the type as
>"class x" or "struct x" as appropriate. Currently, for gcc built debug info,
>we have to take a guess.

If you mean 'reflect what the source code said' then I fully agree.
This was always the intent of DWARF (to allow the debugger to report
exactly what the coder said in the source code).  gcc is making
it difficult for the debugger to achieve this goal.

>It also makes sense to only accept the correct kind of tag when evaluating a
>type cast expression. e.g. only accept "(struct x*) 0x1000" when x is a
>struct and not "(class x*) 0x1000".

This is a Quality Of Implementation issue.  It is also a matter of taste.
Some feel it's better to 'do what the user clearly means' even if it's
not precisely what the language compiler would accept (I'm firmly in this camp).
But this is straying from DWARF itself, so lets not go too far
down this road...

David Anderson










From eager  Sat Dec 23 20:49:37 2006
From: eager (Michael Eager)
Date: Sat, 23 Dec 2006 12:49:37 -0800
Subject: [Dwarf-discuss] tag nesting question
In-Reply-To: <458BBB4B.8050608@altium.nl>
References: <458A6B0D.8040603@altium.nl> <458AD94E.2030704@Sun.COM>	
	<458AE031.7070608@eagercon.com>
	<4aca3dc20612211221i164018d6u10b93b4fa168b64a@mail.gmail.com>
	<458BBB4B.8050608@altium.nl>
Message-ID: <458D9661.9040505@eagercon.com>

Marcel Mettes wrote:
> 
> As being someone who works on debuggers, I would love to see the extra 
> info.
> One of my personal goals for the debugger is that it shows exactly what 
> was present in the original source code that was compiled, so that 
> someone who is debugging may spot an error because of the actual input. 
> Hiding differences like struct versus class is not likely to hide bugs, 
> but in general I prefer as much detail as possible.
> 
> Also, with g++ compiled objects, the debugger must first use some test 
> to detect how to display DW_TAG_struct_type (personally I do not want to 
> see struct when debugging C++) which I do not like much myself. I would 
> like to use as little heuristics as possible, there is enough confusion 
> already :-).

The issue is less about whether to identify that the source was
a class, struct, or union, than how to identify this.  In general,
for small distinctions between essentially identical constructs,
like class, struct, and union, DWARF uses an attribute to distinguish
which appeared in the source.

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




From drow  Mon Dec 25 04:05:31 2006
From: drow (Daniel Jacobowitz)
Date: Sun, 24 Dec 2006 23:05:31 -0500
Subject: [Dwarf-discuss] tag nesting question
In-Reply-To: <458A6B0D.8040603@altium.nl>
References: <458A6B0D.8040603@altium.nl>
Message-ID: <20061225040531.GA29839@nevyn.them.org>

On Thu, Dec 21, 2006 at 12:07:57PM +0100, Marcel Mettes wrote:
>    2. The TASKING compiler nests type TAGS like DW_TAG_base_type,
>       DW_TAG_pointer_type, DW_TAG_union_type or DW_TAG_const_type within
>       DW_TAG_structure_type when used by one of the struct's fields.

I've wondered about this before.  What if the nested tag is named?
Is this a name local to the containing structure (in C++, where that's
meaningful), or a name local to the containing structure's scope, or a
global name?

I ask because I'm pretty sure I've seen compilers report a
DW_TAG_base_type with DW_AT_name: int, inside of a namespace or
structure.  I think they're in error to do so.

-- 
Daniel Jacobowitz
CodeSourcery




