From gireeshin@gmail.com  Wed Mar  7 08:39:01 2007
From: gireeshin@gmail.com (gireesh subramaniam)
Date: Wed, 7 Mar 2007 14:09:01 +0530
Subject: [Dwarf-discuss] regarding listing class members
Message-ID: <f459ec1b0703070039m4b15ee39h3a5ea0c69136fcb6@mail.gmail.com>

hello all,
i am Gireesh,currently working on developing a source code browser using the
obj files .

The aim as of now is to list all the members (data members and
methods,included)of a class irrespective of whether they are private,public
or protected.


 I have a specific query,this is from the official pdf of DWARF2 from the
free standards website

"The members of a structure, union, or class are represented by debugging
information entries that
are owned by the corresponding structure type, union type, or class type
entry and appear in the
same order as the corresponding declarations in the source program."

Now,what is the exact meaning of this "ownership",i tried reading the
dwarfdump but there is no mention of the exact relationship with respect to
the offset or which compilation unit it is present.


Can anyone suggest an idea for this...


Regards and Thanks,

Gireesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20070307/e34e6bf9/attachment.htm>


From davea42@earthlink.net  Wed Mar  7 15:57:28 2007
From: davea42@earthlink.net (David Anderson)
Date: Wed, 07 Mar 2007 07:57:28 -0800
Subject: [Dwarf-discuss] regarding listing class members
In-Reply-To: <f459ec1b0703070039m4b15ee39h3a5ea0c69136fcb6@mail.gmail.com>
References: <f459ec1b0703070039m4b15ee39h3a5ea0c69136fcb6@mail.gmail.com>
Message-ID: <45EEE0E8.9040106@earthlink.net>

gireesh subramaniam wrote:
> "The members of a structure, union, or class are represented by debugging
> information entries that
> are owned by the corresponding structure type, union type, or class type
> entry and appear in the
> same order as the corresponding declarations in the source program."
>
> Now,what is the exact meaning of this "ownership",i tried reading the
> dwarfdump but there is no mention of the exact relationship with 
> respect to
> the offset or which compilation unit it is present.
>
Section 2.3 "Relationship of Debugging Information Entries"
defines ownership.   Glossing over details, DIEs  are a conceptual
tree where the tree-parent of a node "owns" it.

(the section 2.3 wording is essentially identical in dwarf2 and dwarf3).

Hope this helps.
David Anderson



From gireeshin@gmail.com  Wed Mar  7 17:00:37 2007
From: gireeshin@gmail.com (gireesh subramaniam)
Date: Wed, 7 Mar 2007 22:30:37 +0530
Subject: [Dwarf-discuss] regarding listing class members
In-Reply-To: <45EEE0E8.9040106@earthlink.net>
References: <f459ec1b0703070039m4b15ee39h3a5ea0c69136fcb6@mail.gmail.com>
	<45EEE0E8.9040106@earthlink.net>
Message-ID: <f459ec1b0703070900x670ea5g8ce7f09bd4fec390@mail.gmail.com>

hello all,
   i read the information in section 2.3 of the DWARF document,but however
contrary to the notion of  the members of a class forming a graph ,i am not
able to find the exact link between the class ,the supposed owner,and the
members.Here i have included one part of the dwarfdump for asource file

in this file:
CLASS name:base
member        :int i

i have pasted the .debug_info sections of the dwarfdump corresponding to
this.


<1><5b>: Abbrev Number: 2 (DW_TAG_structure_type)
     DW_AT_sibling     : <f3>
     DW_AT_name        : base
     DW_AT_byte_size   : 4
     DW_AT_decl_file   : 1
     DW_AT_decl_line   : 3
 <2><68>: Abbrev Number: 3 (DW_TAG_member)
     DW_AT_name        : i
     DW_AT_decl_file   : 1
     DW_AT_decl_line   : 5
     DW_AT_type        : <f3>
     DW_AT_data_member_location: 2 byte block: 23 0     (DW_OP_plus_uconst:
0)
     DW_AT_accessibility: 3    (private)



Before i conclude,i would like to thank everyone those who have taken the
pain to reply,also i am able to see that the data members of the class are
in consecutive locations in the info section,so to list all the members
should i use only this piece of information or is there any other efficient
way to achieve this.

regards and thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20070307/e0f0340f/attachment.htm>


From jdelsign@etnus.com  Wed Mar  7 17:19:19 2007
From: jdelsign@etnus.com (John DelSignore)
Date: Wed, 07 Mar 2007 12:19:19 -0500
Subject: [Dwarf-discuss] regarding listing class members
In-Reply-To: <f459ec1b0703070900x670ea5g8ce7f09bd4fec390@mail.gmail.com>
References: <f459ec1b0703070039m4b15ee39h3a5ea0c69136fcb6@mail.gmail.com>	<45EEE0E8.9040106@earthlink.net>
	<f459ec1b0703070900x670ea5g8ce7f09bd4fec390@mail.gmail.com>
Message-ID: <45EEF417.1020607@etnus.com>

For readelf output, the number in angle brackets to the far left represents the nesting level of the DIE. Other dwarf dumpers might represent nesting differently. In your example, this text:

  <1><5b>: Abbrev Number: 2 (DW_TAG_structure_type)

means nesting level <1>, DIE number <5b>. And this text:

  <2><68>: Abbrev Number: 3 (DW_TAG_member)

means nesting level <2>, DIE number <68>.

The nesting level represents the parent-child relationship the tree, so since DIE <68> follows DIE <5b>, and the nesting level of DIE <68> is 1 greater than DIE <5b>, DIE <68> is a child of DIE <5b>, thus DIE <68> is owned by DIE <5b>.

Cheers, John D.


gireesh subramaniam wrote:
> hello all,
>    i read the information in section 2.3 of the DWARF document,but 
> however contrary to the notion of  the members of a class forming a 
> graph ,i am not able to find the exact link between the class ,the 
> supposed owner,and the members.Here i have included one part of the 
> dwarfdump for asource file
> 
> in this file:
> CLASS name:base
> member        :int i
> 
> i have pasted the .debug_info sections of the dwarfdump corresponding to 
> this.
>   
> 
> <1><5b>: Abbrev Number: 2 (DW_TAG_structure_type)
>      DW_AT_sibling     : <f3>   
>      DW_AT_name        : base   
>      DW_AT_byte_size   : 4   
>      DW_AT_decl_file   : 1   
>      DW_AT_decl_line   : 3   
>  <2><68>: Abbrev Number: 3 (DW_TAG_member)
>      DW_AT_name        : i   
>      DW_AT_decl_file   : 1   
>      DW_AT_decl_line   : 5   
>      DW_AT_type        : <f3>   
>      DW_AT_data_member_location: 2 byte block: 23 0     
> (DW_OP_plus_uconst: 0)
>      DW_AT_accessibility: 3    (private)
> 
> 
> 
> Before i conclude,i would like to thank everyone those who have taken 
> the pain to reply,also i am able to see that the data members of the 
> class are in consecutive locations in the info section,so to list all 
> the members should i use only this piece of information or is there any 
> other efficient way to achieve this.
> 
> regards and thanks.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dwarf-discuss mailing list
> dwarf-discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org



From davea42@earthlink.net  Wed Mar  7 17:21:01 2007
From: davea42@earthlink.net (David Anderson)
Date: Wed, 07 Mar 2007 09:21:01 -0800
Subject: [Dwarf-discuss] regarding listing class members
In-Reply-To: <f459ec1b0703070900x670ea5g8ce7f09bd4fec390@mail.gmail.com>
References: <f459ec1b0703070039m4b15ee39h3a5ea0c69136fcb6@mail.gmail.com>	
	<45EEE0E8.9040106@earthlink.net>
	<f459ec1b0703070900x670ea5g8ce7f09bd4fec390@mail.gmail.com>
Message-ID: <45EEF47D.6000906@earthlink.net>

gireesh subramaniam wrote:
> hello all,
>   i read the information in section 2.3 of the DWARF document,but however
> contrary to the notion of  the members of a class forming a graph ,i 
> am not
> able to find the exact link between the class ,the supposed owner,and the
> members.Here i have included one part of the dwarfdump for asource file
>
> in this file:
> CLASS name:base
> member        :int i
>
> i have pasted the .debug_info sections of the dwarfdump corresponding to
> this.
>
>
> <1><5b>: Abbrev Number: 2 (DW_TAG_structure_type)
>     DW_AT_sibling     : <f3>
>     DW_AT_name        : base
>     DW_AT_byte_size   : 4
>     DW_AT_decl_file   : 1
>     DW_AT_decl_line   : 3
> <2><68>: Abbrev Number: 3 (DW_TAG_member)
>     DW_AT_name        : i
>     DW_AT_decl_file   : 1
>     DW_AT_decl_line   : 5
>     DW_AT_type        : <f3>
>     DW_AT_data_member_location: 2 byte block: 23 0     
> (DW_OP_plus_uconst:
> 0)
>     DW_AT_accessibility: 3    (private)
>

Ah. A small hint:

The leading <2> in 
    <2><68>: Abbrev Number: 3 (DW_TAG_member)
means that this is 'level 2' of the tree.

So the level-2 member is owned by the preceeding level-1 
DW_TAG_structure_type.

Because DIEs can be quite deeply nested, dwarfdump does not
indent it's output (generally).

Try
    dwarfdump -i -d
which not only puts each DIE on a single line, it
indents slightly.

DavidAnderson







From gireeshin@gmail.com  Wed Mar  7 17:26:58 2007
From: gireeshin@gmail.com (gireesh subramaniam)
Date: Wed, 7 Mar 2007 22:56:58 +0530
Subject: [Dwarf-discuss] regarding listing class members
In-Reply-To: <45EEF47D.6000906@earthlink.net>
References: <f459ec1b0703070039m4b15ee39h3a5ea0c69136fcb6@mail.gmail.com>
	<45EEE0E8.9040106@earthlink.net>
	<f459ec1b0703070900x670ea5g8ce7f09bd4fec390@mail.gmail.com>
	<45EEF47D.6000906@earthlink.net>
Message-ID: <f459ec1b0703070926p5764dc43le3f4b46e37ea7daa@mail.gmail.com>

thanks for the information on the nesting levels..but how do i access these
> and how to take care of the nesting.should i make provisions for that in
> my program or does dwarf have any features for it.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20070307/9060a46e/attachment.htm>


From cary@cup.hp.com  Wed Mar  7 18:20:59 2007
From: cary@cup.hp.com (Cary Coutant)
Date: Wed, 7 Mar 2007 10:20:59 -0800
Subject: [Dwarf-discuss] Constant expressions in locations lists
Message-ID: <41DCADEA-9C39-41A4-A321-CE7DA71E4AFD@cup.hp.com>

A problem we've come up with in improving our support for optimized  
code on HP-UX is in trying to describe a variable that sometimes has  
a constant value (not available in memory or in a register) during  
portions of its live range. A variable that is constant everywhere  
can be described by DW_AT_const_value, but there is no way (that I  
can see) to represent a constant value in a location list.

If I'm missing something that would allow this, I'd be happy to learn  
of it. Otherwise, I have a fairly simple suggestion:

I propose to add a new "DW_OP_addressof" operator (it could also be  
named "DW_OP_ref" or "DW_OP_lvalue" -- I haven't picked a favorite  
yet) that would turn the value on the top of the stack into a  
reference to that constant value. A location expression ending with  
this operator would be valid anywhere a DW_OP_regx operator is valid,  
and could also be applied to the portion of a location expression  
described by DW_OP_piece.

An alternative that we considered was to extend the location list  
definition to provide a way of distinguishing each location list  
entry as either a location expression or a constant value. I prefer  
the new operator, though, as it's more flexible and less impact  
overall to the DWARF spec.

-cary




From jimb@red-bean.com  Wed Mar  7 18:42:34 2007
From: jimb@red-bean.com (Jim Blandy)
Date: Wed, 7 Mar 2007 10:42:34 -0800
Subject: [Dwarf-discuss] Constant expressions in locations lists
In-Reply-To: <41DCADEA-9C39-41A4-A321-CE7DA71E4AFD@cup.hp.com>
References: <41DCADEA-9C39-41A4-A321-CE7DA71E4AFD@cup.hp.com>
Message-ID: <8f2776cb0703071042m203495edh6e25c1f412e67210@mail.gmail.com>

On 3/7/07, Cary Coutant <cary at cup.hp.com> wrote:
> I propose to add a new "DW_OP_addressof" operator (it could also be
> named "DW_OP_ref" or "DW_OP_lvalue" -- I haven't picked a favorite
> yet) that would turn the value on the top of the stack into a
> reference to that constant value. A location expression ending with
> this operator would be valid anywhere a DW_OP_regx operator is valid,
> and could also be applied to the portion of a location expression
> described by DW_OP_piece.

I think an expression operator might be a nice way to solve this, but
DW_OP_addressof has some difficulties.  The values on the stack are
always address-sized, so you would have difficulty producing constant
values of floating-point, very large integer, or structure types.

Perhaps an operator DW_OP_constant, followed by an LEB128 size,
followed by that many bytes of data in target form, permitted to
appear wherever a location expression may occur.

(The spec really needs a grammar for location expressions; writing out
grammar rules in English is clumsy.)



From davea42@earthlink.net  Wed Mar  7 18:41:23 2007
From: davea42@earthlink.net (David Anderson)
Date: Wed, 07 Mar 2007 10:41:23 -0800
Subject: [Dwarf-discuss] regarding listing class members
In-Reply-To: <f459ec1b0703070926p5764dc43le3f4b46e37ea7daa@mail.gmail.com>
References: <f459ec1b0703070039m4b15ee39h3a5ea0c69136fcb6@mail.gmail.com>	
	<45EEE0E8.9040106@earthlink.net>	
	<f459ec1b0703070900x670ea5g8ce7f09bd4fec390@mail.gmail.com>	
	<45EEF47D.6000906@earthlink.net>
	<f459ec1b0703070926p5764dc43le3f4b46e37ea7daa@mail.gmail.com>
Message-ID: <45EF0753.2080407@earthlink.net>

gireesh subramaniam wrote:
> thanks for the information on the nesting levels..but how do i access 
> these
>> and how to take care of the nesting.should i make provisions for that in
>> my program or does dwarf have any features for it.
>>
>>
>
What does 'access' mean in your email?  (Rhetorical question)

Write a script or program that reads output from dwarfdump (or readelf, 
a GNU  binutils
tool) and which does what you want.
Or write code that reads the object file directly and decodes the DWARF 
information.

You will surely need to build data structures to capture the information
of interest.

I suspect you have enough information to proceed. But that does
not mean your task is easy  :-)
Programs are complicated, the relationships are complicated (especially
in C++ and Ada, and Fortran gets
more complicated all the time).  So the DWARF to express the 
relationships is complicated.

DavidAnderson



From gireeshin@gmail.com  Wed Mar  7 19:16:59 2007
From: gireeshin@gmail.com (gireesh subramaniam)
Date: Thu, 8 Mar 2007 00:46:59 +0530
Subject: [Dwarf-discuss] regarding listing class members
In-Reply-To: <45EF0753.2080407@earthlink.net>
References: <f459ec1b0703070039m4b15ee39h3a5ea0c69136fcb6@mail.gmail.com>
	<45EEE0E8.9040106@earthlink.net>
	<f459ec1b0703070900x670ea5g8ce7f09bd4fec390@mail.gmail.com>
	<45EEF47D.6000906@earthlink.net>
	<f459ec1b0703070926p5764dc43le3f4b46e37ea7daa@mail.gmail.com>
	<45EF0753.2080407@earthlink.net>
Message-ID: <f459ec1b0703071116n26293a61y93cc30d1c3ad7d7d@mail.gmail.com>

no, the problem is not building datastructures but to keep track of the
nesting level and to decide whether or not to to continue with the nesting
and when to stop it.i still dont have a clear idea as to how the nesting
level info of the DIE's will be repesented in the .o file,and these are the
stuff i meant when i said accessing the information.

thanks and regards,
Gireesh.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20070308/9586ee46/attachment.htm>


From eager@eagercon.com  Wed Mar  7 19:42:54 2007
From: eager@eagercon.com (Michael Eager)
Date: Wed, 07 Mar 2007 11:42:54 -0800
Subject: [Dwarf-discuss] regarding listing class members
In-Reply-To: <f459ec1b0703071116n26293a61y93cc30d1c3ad7d7d@mail.gmail.com>
References: <f459ec1b0703070039m4b15ee39h3a5ea0c69136fcb6@mail.gmail.com>	<45EEE0E8.9040106@earthlink.net>	<f459ec1b0703070900x670ea5g8ce7f09bd4fec390@mail.gmail.com>	<45EEF47D.6000906@earthlink.net>	<f459ec1b0703070926p5764dc43le3f4b46e37ea7daa@mail.gmail.com>	<45EF0753.2080407@earthlink.net>
	<f459ec1b0703071116n26293a61y93cc30d1c3ad7d7d@mail.gmail.com>
Message-ID: <45EF15BE.8040602@eagercon.com>

gireesh subramaniam wrote:
> 
> 
> no, the problem is not building datastructures but to keep track of the 
> nesting level and to decide whether or not to to continue with the 
> nesting and when to stop it.i still dont have a clear idea as to how the 
> nesting level info of the DIE's will be repesented in the .o file,and 
> these are the stuff i meant when i said accessing the information.

The nesting level is represented by the DIE tree.  Each DIE
has (potentially) one or more children.  Consult the description
of how DIEs are encoded in the .debug_info section for a detailed
description of how this is represented.

Looking at the code in readelf or libdwarf may help you get a better
understanding.

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



From dberlin@dberlin.org  Wed Mar  7 22:12:11 2007
From: dberlin@dberlin.org (Daniel Berlin)
Date: Wed, 7 Mar 2007 17:12:11 -0500
Subject: [Dwarf-discuss] Constant expressions in locations lists
In-Reply-To: <41DCADEA-9C39-41A4-A321-CE7DA71E4AFD@cup.hp.com>
References: <41DCADEA-9C39-41A4-A321-CE7DA71E4AFD@cup.hp.com>
Message-ID: <4aca3dc20703071412m2c2ff5advdabb2a8c7df114c@mail.gmail.com>

On 3/7/07, Cary Coutant <cary at cup.hp.com> wrote:
> A problem we've come up with in improving our support for optimized
> code on HP-UX is in trying to describe a variable that sometimes has
> a constant value (not available in memory or in a register) during
> portions of its live range. A variable that is constant everywhere
> can be described by DW_AT_const_value, but there is no way (that I
> can see) to represent a constant value in a location list.

There isn't.  For GCC, we actually punt and say the value is optimized
out during that portion, even though we know what the value is :(.

> I propose to add a new "DW_OP_addressof" operator (it could also be
> named "DW_OP_ref" or "DW_OP_lvalue" -- I haven't picked a favorite
> yet) that would turn the value on the top of the stack into a
> reference to that constant value. A location expression ending with
> this operator would be valid anywhere a DW_OP_regx operator is valid,
> and could also be applied to the portion of a location expression
> described by DW_OP_piece.
>
Why not just a DW_OP_constant_value?



From cary@cup.hp.com  Wed Mar  7 23:39:54 2007
From: cary@cup.hp.com (Cary Coutant)
Date: Wed, 7 Mar 2007 15:39:54 -0800
Subject: [Dwarf-discuss] Constant expressions in locations lists
In-Reply-To: <8f2776cb0703071042m203495edh6e25c1f412e67210@mail.gmail.com>
References: <41DCADEA-9C39-41A4-A321-CE7DA71E4AFD@cup.hp.com>
	<8f2776cb0703071042m203495edh6e25c1f412e67210@mail.gmail.com>
Message-ID: <ADF78B12-5A03-41D3-A18F-7C09823ACEAE@cup.hp.com>

Jim Blandy wrote:
> I think an expression operator might be a nice way to solve this, but
> DW_OP_addressof has some difficulties.  The values on the stack are
> always address-sized, so you would have difficulty producing constant
> values of floating-point, very large integer, or structure types.
>
> Perhaps an operator DW_OP_constant, followed by an LEB128 size,
> followed by that many bytes of data in target form, permitted to
> appear wherever a location expression may occur.

and Daniel Berlin wrote:
> Why not just a DW_OP_constant_value?

Yes, this is probably better.

I did consider that approach, but it seemed potentially confusing,  
given that it would be quite different from the existing DW_OP_const*  
and DW_OP_lit* operators. Nevertheless, Jim's point about large  
values is a good one, and I think it overrides my concern about  
confusion. If this new operator were introduced in Section 2.5.1 (or  
in a new section immediately following), it could be made clear that  
this operator provides a constant value as opposed to a constant to  
be used for address computation. The rules for its use, I think,  
could be exactly the same as those for DW_OP_reg*, and could be used  
as part of a DW_OP_piece construction as well.

> (The spec really needs a grammar for location expressions; writing out
> grammar rules in English is clumsy.)

I think what it needs isn't so much a grammar as a type system. The  
grammar for a postfix expression on a simple stack is trivial.  
Consider introducing four types of values that can exist on the  
stack: integers, register names, constant values, and "pieces". Now  
each operator can be described in terms of what types of values it  
can consume from the stack and what type of value it pushes back onto  
the stack (if any):

- The DW_OP_const* and DW_OP_lit* operators push an integer onto the  
stack.
- The DW_OP_reg* operators push a register name.
- The DW_OP_constant_value operator pushes a constant value.
- The DW_OP_piece (and DW_OP_bit_piece, if that's in yet) operator  
can consume any one of the other three types, and pushes a "piece"  
back onto the stack.
- Most of the remaining operators consume one or two integers and  
push an integer.

At the end of the expression, we must have a stack that has either  
(a) exactly one value of type integer, register name, or constant  
value; or (b) one or more values of type "piece". (In other words, if  
the stack contains more than one value at the end, they must all be  
"pieces".)

(DW_OP_skip and DW_OP_bra may take a little additional descriptive  
effort, but as long as expression validity is defined in terms of  
what kinds of values can be consumed by each operator and what the  
stack has to look like at the end, it should be complete.)

This relates back to an April 2005 discussion on this list about  
DW_OP_piece. That discussion suggested treating DW_OP_piece as  
removing a value from the stack and contributing a piece description  
"somewhere else". I think using separate types makes it conceptually  
clearer, and the allowable expressions are constrained by the types  
that each operator can consume and the requirements for the ending  
contents of the stack.

-cary






From davea42@earthlink.net  Thu Mar  8 01:45:31 2007
From: davea42@earthlink.net (David Anderson)
Date: Wed, 07 Mar 2007 17:45:31 -0800
Subject: [Dwarf-discuss] Constant expressions in locations lists
In-Reply-To: <ADF78B12-5A03-41D3-A18F-7C09823ACEAE@cup.hp.com>
References: <41DCADEA-9C39-41A4-A321-CE7DA71E4AFD@cup.hp.com>	<8f2776cb0703071042m203495edh6e25c1f412e67210@mail.gmail.com>
	<ADF78B12-5A03-41D3-A18F-7C09823ACEAE@cup.hp.com>
Message-ID: <45EF6ABB.7030305@earthlink.net>

Cary Coutant wrote:
>
> I think what it needs isn't so much a grammar as a type system. The  
> grammar for a postfix expression on a simple stack is trivial.  
> Consider introducing four types of values that can exist on the  
> stack: integers, register names, constant values, and "pieces". Now  
> each operator can be described in terms of what types of values it  
> can consume from the stack and what type of value it pushes back onto  
> the stack (if any):
>
> - The DW_OP_const* and DW_OP_lit* operators push an integer onto the  
> stack.
> - The DW_OP_reg* operators push a register name.
> - The DW_OP_constant_value operator pushes a constant value.
> - The DW_OP_piece (and DW_OP_bit_piece, if that's in yet) operator  
> can consume any one of the other three types, and pushes a "piece"  
> back onto the stack.
> - Most of the remaining operators consume one or two integers and  
> push an integer.
>   

History note:  We really intended the OP evaluation
stack to have simply 'address size integers'
and avoid such a 'type' system entirely. 
Even avoiding signed/unsigned issues (as that's not a  problem
with twos-complement). 
Not as an oversight, but as a design decision.

Whether that simple address-size-integer
value stack  is still sufficient is open to discussion, but
any type system introduces all the 'conversion' issues.

David Anderson




From marcelm@altium.nl  Thu Mar  8 09:34:16 2007
From: marcelm@altium.nl (Marcel Mettes)
Date: Thu, 08 Mar 2007 10:34:16 +0100
Subject: [Dwarf-discuss] Constant expressions in locations list
In-Reply-To: <mailman.1.1173337733.23896.dwarf-discuss-dwarfstd.org@lists.dwarfstd.org>
References: <mailman.1.1173337733.23896.dwarf-discuss-dwarfstd.org@lists.dwarfstd.org>
Message-ID: <45EFD898.5070605@altium.nl>


> History note:  We really intended the OP evaluation
> stack to have simply 'address size integers'
> and avoid such a 'type' system entirely. 
> Even avoiding signed/unsigned issues (as that's not a  problem
> with twos-complement). 
> Not as an oversight, but as a design decision.
>
> Whether that simple address-size-integer
> value stack  is still sufficient is open to discussion, but
> any type system introduces all the 'conversion' issues.
>
> David Anderson

Perhaps a reference to another DIE or Attribute can be used, where the 
actual constant value is to be found?

I wonder whether constants are limited to scalars or that entire arrays 
or structs can be constant too.

Marcel Mettes



From cary@cup.hp.com  Thu Mar  8 18:52:22 2007
From: cary@cup.hp.com (Cary Coutant)
Date: Thu, 8 Mar 2007 10:52:22 -0800
Subject: [Dwarf-discuss] Constant expressions in locations lists
In-Reply-To: <45EF6ABB.7030305@earthlink.net>
References: <41DCADEA-9C39-41A4-A321-CE7DA71E4AFD@cup.hp.com>	<8f2776cb0703071042m203495edh6e25c1f412e67210@mail.gmail.com>
	<ADF78B12-5A03-41D3-A18F-7C09823ACEAE@cup.hp.com>
	<45EF6ABB.7030305@earthlink.net>
Message-ID: <F6729C25-C584-4F68-B37F-40C8CE840B49@cup.hp.com>

David Anderson wrote:

> History note:  We really intended the OP evaluation
> stack to have simply 'address size integers'
> and avoid such a 'type' system entirely. Even avoiding signed/ 
> unsigned issues (as that's not a  problem
> with twos-complement). Not as an oversight, but as a design decision.
>
> Whether that simple address-size-integer
> value stack  is still sufficient is open to discussion, but
> any type system introduces all the 'conversion' issues.

Nothing in what I suggested would introduce any conversion issues --  
there are no implicit conversions from, say, integer to constant  
value or register name, and there are no operators that would do any  
conversion. The type system is just there to aid the semantic  
description, and isn't meant to suggest any specific implementation.  
In fact, since I'm not proposing to change the semantics -- just a  
way of describing them -- it shouldn't have any impact at all on  
anyone's implementation. The implementations have to deal with  
register names and piece descriptions today, so they must already  
have something more than just a stack of address-size-integers.

-cary




From Chris.Quenelle@Sun.COM  Thu Mar  8 21:04:25 2007
From: Chris.Quenelle@Sun.COM (Chris Quenelle)
Date: Thu, 08 Mar 2007 13:04:25 -0800
Subject: [Dwarf-discuss] Constant expressions in locations lists
In-Reply-To: <ADF78B12-5A03-41D3-A18F-7C09823ACEAE@cup.hp.com>
References: <41DCADEA-9C39-41A4-A321-CE7DA71E4AFD@cup.hp.com>
	<8f2776cb0703071042m203495edh6e25c1f412e67210@mail.gmail.com>
	<ADF78B12-5A03-41D3-A18F-7C09823ACEAE@cup.hp.com>
Message-ID: <45F07A59.5070000@Sun.COM>

I like Cary's idea to help describe the rules we already have in
place for expressions.

I don't like the idea of using DW_AT_location to describe a constant
value for a variable.  It's confusing.

It might be more understandable to add DW_AT_value as an attribute,
make it work just like DW_AT_location, but have it imply that the result
of evaluating the stack is a value instead of a location.
(It could be used as a super-set of DW_AT_location)

Of course, the whole idea that it points to a "location list"
is also confusing....

--chris



Cary Coutant wrote:
> - The DW_OP_const* and DW_OP_lit* operators push an integer onto the  
> stack.
> - The DW_OP_reg* operators push a register name.
> - The DW_OP_constant_value operator pushes a constant value.
> - The DW_OP_piece (and DW_OP_bit_piece, if that's in yet) operator  
> can consume any one of the other three types, and pushes a "piece"  
> back onto the stack.
> - Most of the remaining operators consume one or two integers and  
> push an integer.



From jimb@red-bean.com  Thu Mar  8 22:12:08 2007
From: jimb@red-bean.com (Jim Blandy)
Date: Thu, 8 Mar 2007 14:12:08 -0800
Subject: [Dwarf-discuss] Constant expressions in locations lists
In-Reply-To: <45F07A59.5070000@Sun.COM>
References: <41DCADEA-9C39-41A4-A321-CE7DA71E4AFD@cup.hp.com>
	<8f2776cb0703071042m203495edh6e25c1f412e67210@mail.gmail.com>
	<ADF78B12-5A03-41D3-A18F-7C09823ACEAE@cup.hp.com>
	<45F07A59.5070000@Sun.COM>
Message-ID: <8f2776cb0703081412x598152e5v13739f45c70f5d42@mail.gmail.com>

On 3/8/07, Chris Quenelle <Chris.Quenelle at sun.com> wrote:
> I don't like the idea of using DW_AT_location to describe a constant
> value for a variable.  It's confusing.
>
> It might be more understandable to add DW_AT_value as an attribute,
> make it work just like DW_AT_location, but have it imply that the result
> of evaluating the stack is a value instead of a location.
> (It could be used as a super-set of DW_AT_location)
>
> Of course, the whole idea that it points to a "location list"
> is also confusing....

The case to consider (which I think was brought up) is where a
variable is constant at some points in the code, and has different
homes at other points.  The appeal of a DW_OP_constant_value operator
is that it fits nicely into a location list, and can be used for
pieces of a value that is only partly const.  We could get the same
behavior from a separate attribute, but weaving the two together would
be hairy.

However we decide to do it, we'll need to emphasize that "constant
value" locations are only to be used when a variable has no location,
but its value is known.  For example, immediately after a statement
like:

   a = 3;

the value of a is known to be a constant, but if a is in fact located
in a register which has now had 3 stored into it, describing the
location of a as "a constant" would be annoying, since it would
prevent you from assigning to it even though that's perfectly
feasible.



From davea42@earthlink.net  Thu Mar  8 22:51:53 2007
From: davea42@earthlink.net (David Anderson)
Date: Thu, 08 Mar 2007 14:51:53 -0800
Subject: [Dwarf-discuss] Constant expressions in locations lists
In-Reply-To: <F6729C25-C584-4F68-B37F-40C8CE840B49@cup.hp.com>
References: <41DCADEA-9C39-41A4-A321-CE7DA71E4AFD@cup.hp.com>	<8f2776cb0703071042m203495edh6e25c1f412e67210@mail.gmail.com>
	<ADF78B12-5A03-41D3-A18F-7C09823ACEAE@cup.hp.com>
	<45EF6ABB.7030305@earthlink.net>
	<F6729C25-C584-4F68-B37F-40C8CE840B49@cup.hp.com>
Message-ID: <45F09389.8020505@earthlink.net>

Cary Coutant wrote:
>
> Nothing in what I suggested would introduce any conversion issues -- 
> there are no implicit conversions from, say, integer to constant value 
> or register name, and there are no operators that would do any 
> conversion. The type system is just there to aid the semantic 
> description, and isn't meant to suggest any specific implementation. 
> In fact, since I'm not proposing to change the semantics -- just a way 
> of describing them -- it shouldn't have any impact at all on anyone's 
> implementation. The implementations have to deal with register names 
> and piece descriptions today, so they must already have something more 
> than just a stack of address-size-integers.
Not really.  Having implemented such a thing I'd say that's exactly what 
it is,
a stack of address size integers.  The 'plain register' case being a 
wart :-)
And a different wart for DW_OP_piece (which I never needed to implement
as the compiler involved did not produce such).

I don't understand how, if you have 'types', that one could store such 
on the
simple address-size-entry stack.  And if you had  a type for each entry,
how could DW_OP_plus do anything without some conversion.

I don't mean to be difficult, I just don't get it. Sorry.
I'm sure a complete description of what you mean by types
would answer my questions, and I'm happy to wait for such if
this notion gets general interest (and if it does not get
general interest, then it's moot). 

David Anderson



From Chris.Quenelle@Sun.COM  Thu Mar  8 23:24:19 2007
From: Chris.Quenelle@Sun.COM (Chris Quenelle)
Date: Thu, 08 Mar 2007 15:24:19 -0800
Subject: [Dwarf-discuss] Constant expressions in locations lists
In-Reply-To: <45F09389.8020505@earthlink.net>
References: <41DCADEA-9C39-41A4-A321-CE7DA71E4AFD@cup.hp.com>
	<8f2776cb0703071042m203495edh6e25c1f412e67210@mail.gmail.com>
	<ADF78B12-5A03-41D3-A18F-7C09823ACEAE@cup.hp.com>
	<45EF6ABB.7030305@earthlink.net>
	<F6729C25-C584-4F68-B37F-40C8CE840B49@cup.hp.com>
	<45F09389.8020505@earthlink.net>
Message-ID: <45F09B23.7020909@Sun.COM>


> I don't understand how, if you have 'types', that one could store such 
> on the
> simple address-size-entry stack.  And if you had  a type for each entry,
> how could DW_OP_plus do anything without some conversion.

You don't have "types" in the code.  The types are only in the spec.
That's how it works.

--chris



From cary@cup.hp.com  Fri Mar  9 00:34:49 2007
From: cary@cup.hp.com (Cary Coutant)
Date: Thu, 8 Mar 2007 16:34:49 -0800
Subject: [Dwarf-discuss] Constant expressions in locations lists
In-Reply-To: <45F09389.8020505@earthlink.net>
References: <41DCADEA-9C39-41A4-A321-CE7DA71E4AFD@cup.hp.com>	<8f2776cb0703071042m203495edh6e25c1f412e67210@mail.gmail.com>
	<ADF78B12-5A03-41D3-A18F-7C09823ACEAE@cup.hp.com>
	<45EF6ABB.7030305@earthlink.net>
	<F6729C25-C584-4F68-B37F-40C8CE840B49@cup.hp.com>
	<45F09389.8020505@earthlink.net>
Message-ID: <746E3878-76D2-4225-8BEB-E64C4446D90F@cup.hp.com>

> I don't understand how, if you have 'types', that one could store  
> such on the
> simple address-size-entry stack.  And if you had  a type for each  
> entry,
> how could DW_OP_plus do anything without some conversion.
>
> I don't mean to be difficult, I just don't get it. Sorry.
> I'm sure a complete description of what you mean by types
> would answer my questions, and I'm happy to wait for such if
> this notion gets general interest (and if it does not get
> general interest, then it's moot).

It was meant only as a device for specifying the semantics, nothing  
else. I'll be away from the discussion while I'm on vacation for the  
next 10 days, then I'll see if it's worth developing when I return.

-cary




From cary@cup.hp.com  Fri Mar  9 00:37:26 2007
From: cary@cup.hp.com (Cary Coutant)
Date: Thu, 8 Mar 2007 16:37:26 -0800
Subject: [Dwarf-discuss] Constant expressions in locations lists
In-Reply-To: <8f2776cb0703081412x598152e5v13739f45c70f5d42@mail.gmail.com>
References: <41DCADEA-9C39-41A4-A321-CE7DA71E4AFD@cup.hp.com>
	<8f2776cb0703071042m203495edh6e25c1f412e67210@mail.gmail.com>
	<ADF78B12-5A03-41D3-A18F-7C09823ACEAE@cup.hp.com>
	<45F07A59.5070000@Sun.COM>
	<8f2776cb0703081412x598152e5v13739f45c70f5d42@mail.gmail.com>
Message-ID: <65F217F6-DF09-4554-9150-7CCB3B06B297@cup.hp.com>

> However we decide to do it, we'll need to emphasize that "constant
> value" locations are only to be used when a variable has no location,
> but its value is known.  For example, immediately after a statement
> like:
>
>    a = 3;
>
> the value of a is known to be a constant, but if a is in fact located
> in a register which has now had 3 stored into it, describing the
> location of a as "a constant" would be annoying, since it would
> prevent you from assigning to it even though that's perfectly
> feasible.

Agreed. I'll pick this discussion up again a week from Tuesday when I  
get back from vacation. If you all have settled on a solution by  
then, great!

-cary




From jimb@red-bean.com  Fri Mar  9 01:19:49 2007
From: jimb@red-bean.com (Jim Blandy)
Date: Thu, 8 Mar 2007 17:19:49 -0800
Subject: [Dwarf-discuss] Constant expressions in locations lists
In-Reply-To: <45F09389.8020505@earthlink.net>
References: <41DCADEA-9C39-41A4-A321-CE7DA71E4AFD@cup.hp.com>
	<8f2776cb0703071042m203495edh6e25c1f412e67210@mail.gmail.com>
	<ADF78B12-5A03-41D3-A18F-7C09823ACEAE@cup.hp.com>
	<45EF6ABB.7030305@earthlink.net>
	<F6729C25-C584-4F68-B37F-40C8CE840B49@cup.hp.com>
	<45F09389.8020505@earthlink.net>
Message-ID: <8f2776cb0703081719t6e4ae274h927be7af84d13e55@mail.gmail.com>

On 3/8/07, David Anderson <davea42 at earthlink.net> wrote:
> I don't mean to be difficult, I just don't get it. Sorry.
> I'm sure a complete description of what you mean by types
> would answer my questions, and I'm happy to wait for such if
> this notion gets general interest (and if it does not get
> general interest, then it's moot).

What's really going on here is that an overall grammar for location
expressions and a type system for location expressions are just two
different ways of describing exactly the same set of constraints.  If
your type system is simple enough (and the one Cary had in mind is, if
I understood), then you can actually just express it in the grammar,
and get "syntax error" instead of "type error".  In the
implementation, you'd certainly handle either one as if they were
grammatical constraints; no need to complicate the interpreter.  It's
just a question of how you'd like to say it.

The last time we talked about this, people posted a few different
grammars.  I think they were equivalent, modulo typos; my favorite was
this one (assume 'FOO *' means 'zero or more FOOs' and 'FOO +' means
'one or more FOOs')

location_operator: <any DW_OP_regN or DW_OP_regx>;
normal_operator: <any other DW_OP_ operator>;

dwarf_expression: normal_operator *;

nonempty_dwarf_expression: normal_operator +;

dwarf_simple_location: /* empty --- optimized out */
                     | location_operator   /* in register */
                     | nonempty_dwarf_expression    /* in memory */
                     ;

dwarf_location_expression: dwarf_simple_location
                | piece +
                ;

dwarf_piece: dwarf_simple_location DW_OP_piece N
           | dwarf_simple_location DW_OP_bit_piece N
           ;

I like this because the symbols correspond closely to the terms or
concepts currently used in the spec.  The dwarf_expression symbol
expands to well-formed plain expressions (as for DW_AT_byte_size, for
example), and dwarf_location_expression expands to well-formed DWARF
location expressions.



From gireeshin@gmail.com  Fri Mar  9 06:08:22 2007
From: gireeshin@gmail.com (gireesh subramaniam)
Date: Fri, 9 Mar 2007 11:38:22 +0530
Subject: [Dwarf-discuss] converting code written for 32bit elf to 64 bit...
Message-ID: <f459ec1b0703082208o145429e7wcd9a8f4d80a9c20f@mail.gmail.com>

hello all,
this is gireesh here,

i have written some codes which are compatible for ELF 32 bit format,now to
make the code work for 64 bit format as well ,what are the changes that are
to be made.

With the observations i made,the major difference seems to  be size of ELF
header and section headers,but somehow this alone doesn't seem to do the
trick.

any ideas or suggestions....

regards and thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20070309/0bb2a774/attachment.htm>


From gireeshin@gmail.com  Sat Mar 10 10:29:17 2007
From: gireeshin@gmail.com (gireesh subramaniam)
Date: Sat, 10 Mar 2007 15:59:17 +0530
Subject: [Dwarf-discuss] converting code written for 32bit elf to 64 bit...
In-Reply-To: <45F19717.7090300@earthlink.net>
References: <f459ec1b0703082208o145429e7wcd9a8f4d80a9c20f@mail.gmail.com>
	<45F19717.7090300@earthlink.net>
Message-ID: <f459ec1b0703100229g151d8a6do626a2d44434d616b@mail.gmail.com>

yes,i realise the group for developing DWARF,i just asked whether any of you
have an idea because this sort of stuff is related to usage of DWARF,isn't
it?

but if anyone else has any suggestions,please reply...

as far as what i understand,there seems to alignment problems as well as
size difference between the two formats.

Anyway it's ok,thanks for replying anyway..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20070310/cf2fbdd5/attachment.htm>


From ron.brender@charter.net  Wed Mar 14 22:02:53 2007
From: ron.brender@charter.net (Ron Brender)
Date: Wed, 14 Mar 2007 18:02:53 -0400
Subject: [Dwarf-discuss] Constant expressions in locations lists
In-Reply-To: <ADF78B12-5A03-41D3-A18F-7C09823ACEAE@cup.hp.com>
References: <41DCADEA-9C39-41A4-A321-CE7DA71E4AFD@cup.hp.com>	<8f2776cb0703071042m203495edh6e25c1f412e67210@mail.gmail.com>
	<ADF78B12-5A03-41D3-A18F-7C09823ACEAE@cup.hp.com>
Message-ID: <45F8710D.3050302@charter.net>

Cary Coutant wrote:
> Jim Blandy wrote:
>> I think an expression operator might be a nice way to solve this, but
>> DW_OP_addressof has some difficulties.  The values on the stack are
>> always address-sized, so you would have difficulty producing constant
>> values of floating-point, very large integer, or structure types.
>>
>> Perhaps an operator DW_OP_constant, followed by an LEB128 size,
>> followed by that many bytes of data in target form, permitted to
>> appear wherever a location expression may occur.
> 
> and Daniel Berlin wrote:
>> Why not just a DW_OP_constant_value?
> 
> Yes, this is probably better.
> 
> I did consider that approach, but it seemed potentially confusing,  
> given that it would be quite different from the existing DW_OP_const*  
> and DW_OP_lit* operators. Nevertheless, Jim's point about large  
> values is a good one, and I think it overrides my concern about  
> confusion. If this new operator were introduced in Section 2.5.1 (or  
> in a new section immediately following), it could be made clear that  
> this operator provides a constant value as opposed to a constant to  
> be used for address computation. The rules for its use, I think,  
> could be exactly the same as those for DW_OP_reg*, and could be used  
> as part of a DW_OP_piece construction as well.
>... 

DW_OP_constant_value feels like it is on the right track. Other names 
that might be less confusing vis-a-vis the current DW_OP_const* 
operators might be DW_OP_immediate_value or DW_OP_known_value or 
DW_OP_implicit_value (now just where did that Thesaurus go...). I like 
the name DW_OP_implicit_value personally because it does sort'a suggest 
that there is no specific place where that value can be found (or replaced).

I suggest that the operand begin with a ULEB128 (not LEB128) size which 
is then followed by the given number of bytes of data.

As Cary suggests, this operator functions just like the DW_OP_reg* 
operators; in particular, it does not affect the expression stack and 
must occur alone except as the first operand of a piece expression.

A variation might be a DW_OP_die operator whose single operand would be 
a 4 or 8 byte offset to a DIE in the .debug_info section. Target kinds 
of DIE that make sense are probably only

   . DW_TAG_constant [Sec 4.1] that has a DW_AT_const_value attribute
     (and no DW_AT_location), or

   . DW_AT_enumerator [Sec 5.8]

The advantage of DW_OP_die over DW_OP_implicit_value comes for large 
(aggregate) values which can thus be shared among multiple location 
lists rather than repeated in situ. I suspect, however, that implicit 
values will much more often be small rather than large so I actually 
lean toward the original DW_OP_implicit_value formulation.

Ron




