From todd.allen  Wed Jun  1 15:39:13 2005
From: todd.allen (Todd Allen)
Date: Wed Jun  1 15:39:13 2005
Subject: [Dwarf-discuss] Recovering type definitions
In-Reply-To: <20050526025855.A83509607@nile.gnat.com>
References: <20050526025855.A83509607@nile.gnat.com>
Message-ID: <20050601193909.GA10832@toad.ccur.com>

> 
> Is there a better way of encoding these examples in DWARF?  
> 

FYI: The Concurrent MAXAda description of REC2 would look more like the
following (after removing most of the vendor extensions and some trivia to
cut down on confusion).  Note that, in our implementation, the upper bound is
stored independently of the discriminant, and so there's an artificial member
described with that upper bound.  It uses DW_AT_artificial and has a
DW_AT_description with "n".  If your implementation just reused the
discriminant, you could skip the extra artificial member and just reference
the discriminant directly.

      DIE (0x15)
         DW_TAG_constant
         DW_CHILDREN_no
         DW_AT_type(DW_FORM_ref_addr) (integer)
         DW_AT_artificial(DW_FORM_flag) TRUE
         DW_AT_description(DW_FORM_string) "100"
         DW_AT_const_value(DW_FORM_sdata) 100

      DIE (0x13)
         DW_TAG_structure_type
         DW_CHILDREN_yes
         DW_AT_name(DW_FORM_string) "rec2"

         DIE (0x14)
            DW_TAG_member
            DW_CHILDREN_no
            DW_AT_type(DW_FORM_ref_addr) (teeny)
            DW_AT_data_member_location(DW_FORM_block) [DW_OP_plus_uconst 0]
            DW_AT_discriminant(DW_FORM_flag) TRUE
            DW_AT_name(DW_FORM_string) "n"
            DW_AT_default_value(DW_FORM_ref_addr) 0x15 (21) []

         DIE (0x1a)
            DW_TAG_member
            DW_CHILDREN_no
            DW_AT_type(DW_FORM_ref_addr) (teeny)
            DW_AT_artificial(DW_FORM_flag) TRUE
            DW_AT_data_member_location(DW_FORM_block) [DW_OP_plus_uconst 16]
            DW_AT_description(DW_FORM_string) "n"

         DIE (0x18)
            DW_TAG_array_type
            DW_CHILDREN_yes

            DIE (0x19)
               DW_TAG_subrange_type
               DW_CHILDREN_no
               DW_AT_type(DW_FORM_ref_addr) (integer)
               DW_AT_lower_bound(DW_FORM_sdata) 1
               DW_AT_upper_bound(DW_FORM_ref_addr) 0x1a (26) []

         DIE (0x1b)
            DW_TAG_padding
            DW_CHILDREN_no

         DIE (0x1c)
            DW_TAG_member
            DW_CHILDREN_no
            DW_AT_type(DW_FORM_ref_addr) 0x18 (24)
            DW_AT_data_member_location(DW_FORM_block) ...
            DW_AT_name(DW_FORM_string) "vec2"

         ...

      DIE (0x24)
         DW_TAG_padding
         DW_CHILDREN_no

-- 
Todd Allen
Concurrent Computer Corporation



From john.e.bishop  Thu Jun  2 17:13:46 2005
From: john.e.bishop (Bishop, John E)
Date: Thu Jun  2 17:13:46 2005
Subject: [Dwarf-discuss] Draft 9.1, computed frame base must be unique
Message-ID: <3DEC199BD7489643817ECA151F7C5929013C95E1@pysmsx401.amr.corp.intel.com>

P 41, section 3.3.5

"The computed value [frame base attribute] should
be unique"

Is there a good reason to add this requirement?
What would be harmed if duplicates were permitted?

	-John



From john.e.bishop  Thu Jun  2 17:13:50 2005
From: john.e.bishop (Bishop, John E)
Date: Thu Jun  2 17:13:50 2005
Subject: [Dwarf-discuss] Draft 9.1, Minor typos and re-phrasings
Message-ID: <3DEC199BD7489643817ECA151F7C5929013C95E3@pysmsx401.amr.corp.intel.com>

p 40, section 3.3.4, italicized text:

   There is no ordering requirement for entries...that 
   do not represent formal parameters.

p 41, 3.3.6, non-italicized text requires an order:

   All thrown entries should follow...preceed...

	-John



From john.e.bishop  Thu Jun  2 17:13:54 2005
From: john.e.bishop (Bishop, John E)
Date: Thu Jun  2 17:13:54 2005
Subject: [Dwarf-discuss] Draft 9.1, Minor typos and re-phrasings
Message-ID: <3DEC199BD7489643817ECA151F7C5929013C95E4@pysmsx401.amr.corp.intel.com>

Using Draft 9.1:

p 20, section 2.5

The bullet points should be followed by a blank
line, as they are in Draft 9.

p 20, section 2.5.1

Point 2 has "encodes the name of a register", when
the code is a LEB128 and thus a _number_.

p 21, section 2.5.3

The example for "DW_OP_fbreg -50" has the op-code
"OPBREG31".  Presumably this is really "DW_OP_breg31"

p 45, section 3.3.8.3, last line

"However, it is not required that .... are owned..."
Should be "...be owned...".

p 48, section 3.7

"The first sibling of each try block entry will be a catch block entry"


Presumably this is the corresponding entry, and "a catch block
entry" should be replaced by "its catch block entry".

p 49, section 4.1, bullet 3

"...which indicates that this entry..."  
Should be "...which indicates whether this entry..."

p 50, section 4.1, bullet 10
"One way...is for a formal parameter...a call that is inlined"
Should be "One way..is a formal parameter...a particular 
inlined call"

p 59, section 5.6.1

Mostly the draft uses "...is a child of...", but here (and in
some other places, I believe) it uses "...is owned by...".

If they mean the same thing, only one phrase should be used.
If they mean something different, they should be defined 
somewhere.

  -John



From john.e.bishop  Thu Jun  2 17:13:55 2005
From: john.e.bishop (Bishop, John E)
Date: Thu Jun  2 17:13:55 2005
Subject: [Dwarf-discuss] Draft 9.1,
	missing "length" and "offset" entries in section 7.5.6
Message-ID: <3DEC199BD7489643817ECA151F7C5929013C95E5@pysmsx401.amr.corp.intel.com>

page 106, 107; section 7.5.6

Entries are needed for "length" and "offset", even if they
are then explained in terms of other things (i.e. constants).

The two need index hits as well.

	-John



From john.e.bishop  Thu Jun  2 17:13:55 2005
From: john.e.bishop (Bishop, John E)
Date: Thu Jun  2 17:13:55 2005
Subject: [Dwarf-discuss] Draft 9.1, section 7.19, offset to what?
Message-ID: <3DEC199BD7489643817ECA151F7C5929013C95E6@pysmsx401.amr.corp.intel.com>

p 123, section 7.19, last paragraph

   "This header is followed by a series of tuples.  Each
   tuple consists of a 4-byte or 8-byte offest followed by
   a string of non-null bytes terminated by one null byte."

What is the offset an offset to?   From what base address
is it an offset?

	-John  



From john.e.bishop  Thu Jun  2 17:15:08 2005
From: john.e.bishop (Bishop, John E)
Date: Thu Jun  2 17:15:08 2005
Subject: [Dwarf-discuss] RE: Draft 9.1,
	conflict (was "Minor typos and re-phrasings")
Message-ID: <3DEC199BD7489643817ECA151F7C5929013C95E9@pysmsx401.amr.corp.intel.com>

Wrong cut-and-paste of subject heading, sorry! 

-----Original Message-----
From: Bishop, John E 
Sent: Thursday, June 02, 2005 5:14 PM
To: dwarf-discuss at base3.freestandards.org
Subject: Draft 9.1, Minor typos and re-phrasings

p 40, section 3.3.4, italicized text:

   There is no ordering requirement for entries...that 
   do not represent formal parameters.

p 41, 3.3.6, non-italicized text requires an order:

   All thrown entries should follow...preceed...

	-John



From john.e.bishop  Fri Jun  3 14:13:50 2005
From: john.e.bishop (Bishop, John E)
Date: Fri Jun  3 14:13:50 2005
Subject: [Dwarf-discuss] Draft 9.1, index
Message-ID: <3DEC199BD7489643817ECA151F7C592901403A02@pysmsx401.amr.corp.intel.com>

An index hit is needed for "prologue" (pp 79, 80, 86).

An index hit is needed for "epilogue" (pp 79, 80, 86)

UTF-8 needs a hit for p 3.




From jcownie  Tue Jun  7 09:53:22 2005
From: jcownie (James Cownie)
Date: Tue Jun  7 09:53:22 2005
Subject: [Dwarf-discuss] F9x elemental procedures
Message-ID: <20050607135317.CB16925AD1@amd64.cownie.net>

Folks,

Fortran 90 and later have the concept of an elemental
subroutine/function, which is a function with scalar arguments which can
be called with conformable array arguments. The procedure being applied
to each element of the array arguments.

Unless I'm missing it I don't see anywhere in DWARF where a compiler can
express this property of a procedure to the debugger.

Assuming that I'm not missing it, can I propose that we add a new
attribute which can be used with procedures, something like this...

In section 3.3.1 (page 39 of draft 9.1) after the italic section and
immediately before 3.3.3 add

  If a function may be applied elementally (i.e. it is a function with scalar
  formals which can be applied to array actuals, with the effect of
  applying the procedure to every element of the array) then the
  subroutine entry should have a DW_AT_elemental attribute with the flag
  set true.

Then we need to add DW_AT_elemental to the attribute table on page 8
  
  DW_AT_elemental	    elemental property of a procedure.

and give it a value in Fig 19 on page 113, presumably 

  DW_AT_elemental           0x61      flag

-- 
-- Jim
--
James Cownie	<jcownie at etnus.com>
Etnus, LLC.     +44 117 9071438
http://www.etnus.com



From Chris.Quenelle  Tue Jun  7 14:33:19 2005
From: Chris.Quenelle (Chris Quenelle)
Date: Tue Jun  7 14:33:19 2005
Subject: [Dwarf-discuss] F9x elemental procedures
In-Reply-To: <20050607135317.CB16925AD1@amd64.cownie.net>
References: <20050607135317.CB16925AD1@amd64.cownie.net>
Message-ID: <42A5E818.3060407@Sun.COM>


 >   (i.e. it is a function with scalar
 >   formals which can be applied to array actuals, with the effect of
 >   applying the procedure to every element of the array)


Can you tell me what "can be applied" means in this context?

Is this describing a function body (code) that that has a special kind of
function call interface?

Is this describing a function declaration that describes a compiler-builtin?

Will a debugger be expected to call these functions in a special way
if it has support for such "elemental" functions?



--chris




James Cownie wrote:
> Folks,
> 
> Fortran 90 and later have the concept of an elemental
> subroutine/function, which is a function with scalar arguments which can
> be called with conformable array arguments. The procedure being applied
> to each element of the array arguments.
> 
> Unless I'm missing it I don't see anywhere in DWARF where a compiler can
> express this property of a procedure to the debugger.
> 
> Assuming that I'm not missing it, can I propose that we add a new
> attribute which can be used with procedures, something like this...
> 
> In section 3.3.1 (page 39 of draft 9.1) after the italic section and
> immediately before 3.3.3 add
> 
>   If a function may be applied elementally (i.e. it is a function with scalar
>   formals which can be applied to array actuals, with the effect of
>   applying the procedure to every element of the array) then the
>   subroutine entry should have a DW_AT_elemental attribute with the flag
>   set true.
> 
> Then we need to add DW_AT_elemental to the attribute table on page 8
>   
>   DW_AT_elemental	    elemental property of a procedure.
> 
> and give it a value in Fig 19 on page 113, presumably 
> 
>   DW_AT_elemental           0x61      flag
> 



From davea  Tue Jun  7 19:00:57 2005
From: davea (David Anderson)
Date: Tue Jun  7 19:00:57 2005
Subject: [Dwarf-discuss] F9x elemental procedures
References: <20050607135317.CB16925AD1@amd64.cownie.net>
Message-ID: <200506072256.j57Muou3720267@quasar.engr.sgi.com>



Comments based on my quick reading of parts of the standard follow.
I'll be interested if James or others think I've got it wrong
(I may well have).

James C
 >   (i.e. it is a function with scalar
 >   formals which can be applied to array actuals, with the effect of
 >   applying the procedure to every element of the array)

Chris Q:
>Can you tell me what "can be applied" means in this context?

It's like a for-loop (as described in F90 std)

>Is this describing a function body (code) that that has a special kind of
>function call interface?

It's like an implied-do in fortran io, but in this case
an implied loop-on-call. The function implementations take, for
example, a double as argument, yet the coder  codes an array
as the argument. and the generated code must iterate over
the elements calling once per element.

>Is this describing a function declaration that describes a compiler-builtin?

Yes, in some cases (at least one).
It's more like the implied-do of a non-builtin (?).

>Will a debugger be expected to call these functions in a special way
>if it has support for such "elemental" functions?

Looks to me like the debugger must do the iteration and call the
implementing function  once for each element. (hmm. well
it gets messy as some arg could be a scalar and other be
an array.)

I must admit I never noticed this feature of F90 before James
mentioned it.
David Anderson



From jcownie  Wed Jun  8 04:43:55 2005
From: jcownie (James Cownie)
Date: Wed Jun  8 04:43:55 2005
Subject: [Dwarf-discuss] F9x elemental procedures 
In-Reply-To: Message from Chris Quenelle <Chris.Quenelle@Sun.COM> 
	of "Tue, 07 Jun 2005 11:31:52 PDT." <42A5E818.3060407@Sun.COM> 
References: <20050607135317.CB16925AD1@amd64.cownie.net>
	<42A5E818.3060407@Sun.COM> 
Message-ID: <20050608084347.812F425A85@amd64.cownie.net>

David's replies are pretty much on the mark.

For full details of how this works in F95, see section 12.5 of the
standard, or (more easily) section 12.5 of the "Fortran 95 Handbook" on
page 467.

There are a few minor corrections 

> >Is this describing a function declaration that describes a compiler-builtin?
> 
> Yes, in some cases (at least one).
> It's more like the implied-do of a non-builtin (?).

I'd say no, it's not describing a compiler built in. 
Or, rather it's not necessary to describe a compiler built in, since
those aren't normally described in the DWARF, so there's nowhere to
describe them, and, since they're in the language spec the debugger
already has all the knowledge it needs to be able to call them.

David is, however, right that many of the Fortran intrinsics are elemental.

FWIW we already handle those in TotalView.
This from the current beta release Totalview shows us applying the sin
and atan2 intrinsics on a two element array

d1.<> dprint sin(r4_a)
 sin (r4_a)      = {
   (1) = -0.97753
   (2) = 0.79849
 }
d1.<> dprint atan2(r4_a,1.0) 
 atan2 (r4_a, 1.0) = {
   (1) = 1.3521
   (2) = 1.4537
 }

> >Will a debugger be expected to call these functions in a special way
> >if it has support for such "elemental" functions?
> 
> Looks to me like the debugger must do the iteration and call the
> implementing function  once for each element. (hmm. well
> it gets messy as some arg could be a scalar and other be
> an array.)

Yes, that's the whole point of giving the debugger the information. It
allows the debugger to know that it should be able to call a function
which has scalar formals even though it is called with array actuals and
one would therefore think that the argument types didn't match. 

The problem this is solving is that the user can write elemental
procedures (functions/subroutines), but the debugger has no way of
discovering which procedures are elemental.

-- 
-- Jim
--
James Cownie	<jcownie at etnus.com>
Etnus, LLC.     +44 117 9071438
http://www.etnus.com




From brender  Wed Jun  8 09:01:48 2005
From: brender (Ron 603-884-2088)
Date: Wed Jun  8 09:01:48 2005
Subject: [Dwarf-discuss] F9x elemental procedures
Message-ID: <05060808425254@gemevn.zko.dec.com>

I believe Dave has more or less the right idea about the meaning of
ELEMENTAL procedures.

If there is more than one array argument, I think the arrays must
have a common shape so that there is only a single iteration involved,
not a cross product. My Fortran manual includes this example, which
I quote:

    MIN(A, 0, B)	! A and B are arrays of shape (S, T)

    In this case the elemental reference to the MIN intrinsic
    function is an array expression whose elements have the
    following values:

    MIN(A(I,J), 0, B(I,J)), I=1,2,...,S, J=1,2,...,T

Note that ELEMENTAL procedures are a special case of PURE
procedures, so if we add/support an DW_AT_elemental attribute
(which I think is a good idea) then I suggest we ought to add
DW_AT_pure as well. In which case we might as well add
DW_AT_recursive to be complete. All three are optional prefixes
on ENTRY and procedure (SUBROUTINE or FUNCTION) statements.

DW_AT_pure and DW_AT_recursive do not involve any additional
support in a debugger beyond just being able to provide a
more complete/accurate reflection of the original source.

FWIW, I think the elemental concept was introduced in Fortran 95
and is not in Fortran 90.

Ron




From jcownie  Wed Jun  8 12:23:58 2005
From: jcownie (James Cownie)
Date: Wed Jun  8 12:23:58 2005
Subject: [Dwarf-discuss] Re: Dwarf-discuss Digest, Vol 10, Issue 6 
In-Reply-To: Message from dwarf-discuss-request@base3.freestandards.org 
	of "Wed,
	08 Jun 2005 12:00:08 EDT." <E1Dg2yO-0007YZ-00@base3.freestandards.org> 
References: <E1Dg2yO-0007YZ-00@base3.freestandards.org> 
Message-ID: <20050608162354.D6F0C25A85@amd64.cownie.net>

Ron wrote :-

> FWIW, I think the elemental concept was introduced in Fortran 95
> and is not in Fortran 90.

I think that's very likely, since ELEMENTAL is an extension of PURE, and
PURE was an HPF feature (like FORALL (well, FORALL was in some of the
F90 drafts, but not the final standard, whereas PURE was invented in
HPF)) which then made its way back into the normal Fortran standard's
track.

-- 
-- Jim
--
James Cownie	<jcownie at etnus.com>
Etnus, LLC.     +44 117 9071438
http://www.etnus.com



From davea  Wed Jun  8 15:13:26 2005
From: davea (David Anderson)
Date: Wed Jun  8 15:13:26 2005
Subject: [Dwarf-discuss] F9x elemental procedures
Message-ID: <200506081632.j58GWl1J682262@quasar.engr.sgi.com>


Ron B:
>FWIW, I think the elemental concept was introduced in Fortran 95
>and is not in Fortran 90.


ISO/IEC 1539:1991(E) has elemental in it.  The one I have
is a draft printed by Global Engineering Documents.
(The 'final' version cost $285 from GED at the time, BTW).


It defines RECURSIVE and elemental, not pure. It has no 
keyword for elemental or pure (does have RECURSIVE keyword).


I'd guess this means you're really correct and it was Fortran95
before elemental was really complete.  But I don't have definitive
documents... So I'm leaving this to those with updated documents!

David A.



From Chris.Quenelle  Thu Jun  9 15:50:47 2005
From: Chris.Quenelle (Chris Quenelle)
Date: Thu Jun  9 15:50:47 2005
Subject: [Dwarf-discuss] F9x elemental procedures
In-Reply-To: <20050607135317.CB16925AD1@amd64.cownie.net>
References: <20050607135317.CB16925AD1@amd64.cownie.net>
Message-ID: <42A89D3F.1040300@Sun.COM>



James Cownie wrote:
> Folks,
> 
> Fortran 90 and later have the concept of an elemental
> subroutine/function, which is a function with scalar arguments which can
> be called with conformable array arguments. The procedure being applied
> to each element of the array arguments.

I discussed this with our fortran team, and my questions
are answered.  I think we should define attributes for
elemental, pure and recursive.

--chris



From drow  Mon Jun 13 18:47:35 2005
From: drow (Daniel Jacobowitz)
Date: Mon Jun 13 18:47:35 2005
Subject: [Dwarf-discuss] DWARF Issue 030812.2
Message-ID: <20050613224732.GA13859@nevyn.them.org>

Re: <a href=http://dwarf.freestandards.org/ShowIssue.php?issue=030812.2>DWARF Issue 030812.2</a>

I think that val_cfa_offset would be clearer than val_offset; every time
I see val_offset, I'm going to ask myself, "offset from what?".

-- 
Daniel Jacobowitz
CodeSourcery, LLC



From todd.allen  Mon Jun 13 19:04:42 2005
From: todd.allen (Todd Allen)
Date: Mon Jun 13 19:04:42 2005
Subject: [Dwarf-discuss] DWARF Issue 030812.2
In-Reply-To: <20050613224732.GA13859@nevyn.them.org>
References: <20050613224732.GA13859@nevyn.them.org>
Message-ID: <20050613230406.GA23751@toad.ccur.com>

On Mon, Jun 13, 2005 at 06:47:32PM -0400, Daniel Jacobowitz wrote:
> Re: <a href=http://dwarf.freestandards.org/ShowIssue.php?issue=030812.2>DWARF Issue 030812.2</a>
> 
> I think that val_cfa_offset would be clearer than val_offset; every time
> I see val_offset, I'm going to ask myself, "offset from what?".
> 

I used val_offset because it's an alternative to offset, which already
is defined.  That is,

   offset:     CFA+offset is the location where the value is stored
   val_offset: CFA+offset is the value itself

So, if val_offset is going to make you ask that, then doesn't the existing
offset make you ask the same question?  I admit these names get confusing.
It seems like almost all of the instructions contain one of the terms cfa or
offset, or both.  (Every time I come across DW_CFA_def_cfa_offset, I think my
head is going to explode.  :-) ).  But I doubt we really want to go back and
change the name of the existing offset rule or its instructions.  And I think
the symmetry of names is useful in order to keep the confusion from getting
completely out of control.

I know that adding an extra cfa into the instruction names probably would
confuse me into thinking it was one of the DW_CFA_def_cfa_* instructions at
some point in the future, after I've had a chance to forget all this again.

-- 
Todd Allen
Concurrent Computer Corporation



From drow  Mon Jun 13 19:08:22 2005
From: drow (Daniel Jacobowitz)
Date: Mon Jun 13 19:08:22 2005
Subject: [Dwarf-discuss] DWARF Issue 030812.2
In-Reply-To: <20050613230406.GA23751@toad.ccur.com>
References: <20050613224732.GA13859@nevyn.them.org>
	<20050613230406.GA23751@toad.ccur.com>
Message-ID: <20050613230818.GA14598@nevyn.them.org>

On Mon, Jun 13, 2005 at 05:04:06PM -0600, Todd Allen wrote:
> On Mon, Jun 13, 2005 at 06:47:32PM -0400, Daniel Jacobowitz wrote:
> > Re: <a href=http://dwarf.freestandards.org/ShowIssue.php?issue=030812.2>DWARF Issue 030812.2</a>
> > 
> > I think that val_cfa_offset would be clearer than val_offset; every time
> > I see val_offset, I'm going to ask myself, "offset from what?".
> > 
> 
> I used val_offset because it's an alternative to offset, which already
> is defined.  That is,
> 
>    offset:     CFA+offset is the location where the value is stored
>    val_offset: CFA+offset is the value itself
> 
> So, if val_offset is going to make you ask that, then doesn't the existing
> offset make you ask the same question?  I admit these names get confusing.

I confess that it does.  However, offset has slightly better internal
consistency: it's a rule, defining an offset for a saved register.  So
having it relative to the CFA makes good sense.  But the CFA is an
awfully arbitrary thing for the value to be offset from.

> I know that adding an extra cfa into the instruction names probably would
> confuse me into thinking it was one of the DW_CFA_def_cfa_* instructions at
> some point in the future, after I've had a chance to forget all this again.

Good point.  *shrug* guess we're confused either way.

-- 
Daniel Jacobowitz
CodeSourcery, LLC



From eager  Tue Jun 14 10:39:18 2005
From: eager (Michael Eager)
Date: Tue Jun 14 10:39:18 2005
Subject: [Dwarf-discuss] Re: Dwarf2 Beginner's Question: Pointer variable
	tracking with Optimization
In-Reply-To: <200506140452.j5E4qRKF021713@scanner2.ics.uci.edu>
References: <200506140452.j5E4qRKF021713@scanner2.ics.uci.edu>
Message-ID: <42AEEBD4.7050908@eagercon.com>

Any DWARF question is appropriate for the mailing list.

Koji Noguchi wrote:
  > Dear Mailing List Members,
> 
> 
> Hi.  I am implementing a simple code/process migration system
> and was wondering if I can use this DWARF2 debug format to solve my problem.
> 
> The problem is, when I decide to migrate the process, I want to know 
> all the (potential) locations of the pointers on the stack and the registers.
> Input is a C code without type casting, union, pointer arithmetic, etc.
> 
> Does DWARF2 provide enough information for this purpose?
> (I'm using gcc with -O3 -g option).
> 
> I think this is not possible, but I wanted to ask you before I 
> completely give up.
> 
> 
> To show how beginner I am, 
> I tried the following simple code but couldn't figure out the 
> register for pointer 'p_int' from the DWARF2 output.
> 
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> #include <stdio.h>
> #include <stdlib.h>
> 
> int main()
> {
>   int aaa,bbb;
>   int * p_int;
> 
>   aaa = 11;
>   bbb = 22;
>   p_int = &bbb;
> 
>   printf( "aaa = %d bbb = %d p_int = %p *p_int = %d\n",
>           aaa, bbb, p_int, *p_int);
>   return 0;
> }
> 
> 
>   .long .LASF46 # DW_AT_name: "p_int"
>   .byte 0x1 # DW_AT_decl_file
>   .byte 0x8 # DW_AT_decl_line
>   .long 0x2f3 # DW_AT_type
>   .byte 0x0 # end of children of DIE 0x2b4
>   .uleb128 0x5  # (DIE (0x2f3) DW_TAG_pointer_type)
>   .byte 0x4 # DW_AT_byte_size
>   .long 0x4f  # DW_AT_type
>   .byte 0x0 # end of children of DIE 0xb
> 
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> 
> I thought the output would contain "DW_AT_location" info somewhere, 
> but I couldn't find it. Am I missing something?
> 
> Any suggestions would be greatly appreciated
> 
> Thank you.
> 
> Koji Noguchi
> 
> 
> 


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



From davea  Tue Jun 14 10:53:12 2005
From: davea (David Anderson)
Date: Tue Jun 14 10:53:12 2005
Subject: [Dwarf-discuss] Re: Dwarf2 Beginner's Question: Pointer variable
	tracking with Optimization
References: <200506140452.j5E4qRKF021713@scanner2.ics.uci.edu>
Message-ID: <200506141449.j5EEnbAd824053@quasar.engr.sgi.com>


Koji Noguchi wrote:
> To show how beginner I am, 
> I tried the following simple code but couldn't figure out the 
> register for pointer 'p_int' from the DWARF2 output.

Few folks would be determined enough to understand
the byte codes.  Instead, produce a .o file and use
readelf (gnu tool) or dwarfdump (from my web site)
to display the .debug_info section readably.

Unless you are diagnosing a compiler bug it's far more sesnsible
to read the formatted output from a dumper tool.

> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> #include <stdio.h>
> #include <stdlib.h>
> 
> int main()
> {
>   int aaa,bbb;
>   int * p_int;
> 
>   aaa = 11;
>   bbb = 22;
>   p_int = &bbb;
> 
>   printf( "aaa = %d bbb = %d p_int = %p *p_int = %d\n",
>           aaa, bbb, p_int, *p_int);
>   return 0;
> }
> 
> 
>   .long .LASF46 # DW_AT_name: "p_int"
>   .byte 0x1 # DW_AT_decl_file
>   .byte 0x8 # DW_AT_decl_line
>   .long 0x2f3 # DW_AT_type
>   .byte 0x0 # end of children of DIE 0x2b4
>   .uleb128 0x5  # (DIE (0x2f3) DW_TAG_pointer_type)
>   .byte 0x4 # DW_AT_byte_size
>   .long 0x4f  # DW_AT_type
>   .byte 0x0 # end of children of DIE 0xb


Regards,
David B. Anderson davea at sgi dot com http://reality.sgiweb.org/davea



From brender  Tue Jun 14 13:45:20 2005
From: brender (Ron 603-884-2088)
Date: Tue Jun 14 13:45:20 2005
Subject: [Dwarf-discuss] Re: Dwarf2 Beginner's Question: Pointer variable...
Message-ID: <05061413265913@gemevn.zko.dec.com>


Koji Noguchi wrote:
> 
> The problem is, when I decide to migrate the process, I want to know 
> all the (potential) locations of the pointers on the stack and the registers.
> Input is a C code without type casting, union, pointer arithmetic, etc.
> 
> Does DWARF2 provide enough information for this purpose?
> (I'm using gcc with -O3 -g option).
> 
> I think this is not possible, but I wanted to ask you before I 
> completely give up.
> 
> To show how beginner I am, 
> I tried the following simple code but couldn't figure out the 
> register for pointer 'p_int' from the DWARF2 output.

The lack of a DW_AT_location attribute on the DIE for p_int
indicates that it has no address. That is, it was "optimized
away". In this example, value propagation might well move the
address of bbb directly into the point of use without ever
allocating a place specifically for p_int.

Of itself, such optimized away variables should not be problem
for your purpose.

However, bear in mind that debugging descriptions (DWARF or
otherwise) generally describe only entities that occur in the
source program. Code generation, especially in optimizing
compilers, can often create additional "variables" for the
convenience of the code generator but which are not described in
the debugging information. Compilers for so-called "garbage
collected languages" generally need to be especially tuned to
avoid creating temporaries that cannot be handled by the runtime
garbage collector.

>From what you have said, this does seem likely to be a problem
for your purposes. But it would take a lot more knowledge about
both the run-time environment and the code generation of that
compiler to be definitive.

Ron Brender




From knoguchi  Wed Jun 15 05:24:14 2005
From: knoguchi (Koji Noguchi)
Date: Wed Jun 15 05:24:14 2005
Subject: [Dwarf-discuss] Re: Dwarf2 Beginner's Question: Pointer
	variable... 
In-Reply-To: Your message of Tue, 14 Jun 2005 13:26:59 PDT"
References: <05061413265913@gemevn.zko.dec.com> 
Message-ID: <200506150923.j5F9NMKF009218@scanner2.ics.uci.edu>

Thank you so much for all the feedbacks.

>>>David Anderson wrote:
 > Instead, produce a .o file and use
 > readelf (gnu tool) or dwarfdump (from my web site)
 > to display the .debug_info section readably.
 >
I see.
I didn't know the difference between the gcc -S -gdwarf-2 -dA output 
and the readelf/dwarfdump outputs.


>>>Ron 603-884-2088 said:
 > 
 > The lack of a DW_AT_location attribute on the DIE for p_int
 > indicates that it has no address. That is, it was "optimized
 > away". In this example, value propagation might well move the
 > address of bbb directly into the point of use without ever
 > allocating a place specifically for p_int.
 > 
Does this mean these two lines 

  p_int = &bbb;
  printf(..., p_int);

can be optimized into the following one line?

  printf(..., &bbb )

In this case, is it possible to determine the register of '&bbb'
from the DWARF output?
I was hoping that the DW_AT_location of 'p_int' would still be the register of 
the '&bbb' even after this 'optimized away' step.

 > 
 > Compilers for so-called "garbage collected languages" generally 
 > need to be especially tuned to avoid creating temporaries that cannot 
 > be handled by the runtime garbage collector.
 >
Thanks.  My goal was to track the pointers without sacrificing 
the optimization, but I guess it was an impossible dream.  


Koji Noguchi





From brender  Wed Jun 15 08:20:58 2005
From: brender (Ron 603-884-2088)
Date: Wed Jun 15 08:20:58 2005
Subject: [Dwarf-discuss] Re: Dwarf2 Beginner's Question: Pointer
	variable...
Message-ID: <05061508113442@gemevn.zko.dec.com>

>>>>Ron 603-884-2088 said:
> > 
> > The lack of a DW_AT_location attribute on the DIE for p_int
> > indicates that it has no address. That is, it was "optimized
> > away". In this example, value propagation might well move the
> > address of bbb directly into the point of use without ever
> > allocating a place specifically for p_int.
> > 
>Does this mean these two lines 
>
>  p_int = &bbb;
>  printf(..., p_int);
>
>can be optimized into the following one line?
>
>  printf(..., &bbb )
>

Absolutely possible, even likely if that is the only use of p_int.

>In this case, is it possible to determine the register of '&bbb'
>from the DWARF output?
>I was hoping that the DW_AT_location of 'p_int' would still be the register of 
>the '&bbb' even after this 'optimized away' step.

It is almost surely impossible to determine the register holding
'&bbb' from the DWARF info. That location would likely be a parameter
passing location, in this example, and unrelated to an user variable.
This is just like

   print(..., x+5 )

where the result of evaluating the expression 'x+5' will end up in
that same parameter passing location, which is not related to whatever
location might hold the value of x.

Ron




From Keith.Walker  Tue Jun 21 13:32:18 2005
From: Keith.Walker (Keith Walker)
Date: Tue Jun 21 13:32:18 2005
Subject: [Dwarf-discuss] FORMs of DW_AT_stride_size in Draft 9
Message-ID: <DD2D1CDF962D7346A5B0E5EE9CA3612704C666FB@ZIPPY.Emea.Arm.com>

In DWARF-3 Draft 9, Figure 18 Attribute Encoding specifies that
DW_AT_stride_size has a class of constant.

Section 2.18 Static and Dynamic Properties of Types has the commentary
statement:
  "The applicable attributes include: DW_AT_allocated, DW_AT_associated,
   DW_AT_bit_offset, DW_AT_bit_size, DW_AT_byte_size, DW_AT_count,
   DW_AT_lower_bound, DW_AT_stride, DW_AT_stride_size, DW_AT_upper_bound
  (and possibly others)."

All the other attribute in this list are specified as having the Classes
block,constant,reference.

I therefore think that it is probably appropriate that the
DW_AT_stride_size also has the Classes block,constant,reference.


Keith Walker, Principle Engineer.
ARM Ltd. Phone: +44 1628 427732

This e-mail message is intended for the addressee(s) only and may
contain information that is the property of, and/or subject to a
confidentiality agreement between the intended recipient(s), their
organisation and/or the ARM Group of Companies. If you are not an
intended recipient of this e-mail message, you should not read, copy,
forward or otherwise distribute or further disclose the information in
it; misuse of the contents of this e-mail message may violate various
laws in your state, country or jurisdiction. If you have received this
e-mail message in error, please contact the originator of this e-mail
message via e-mail and delete all copies of this message from your
computer or network, thank you.
 



From hilfingr  Tue Jun 28 02:38:21 2005
From: hilfingr (Paul Hilfinger)
Date: Tue Jun 28 02:38:21 2005
Subject: [Dwarf-discuss] Encoding fixed-point types
Message-ID: <20050628063809.4E5A897BF@nile.gnat.com>


The Ada language provides fixed-point types, defined to represent a set
of rational numbers consisting of a lower bound added to multiples
of some fixed real increment or delta.   They are sometimes called
scaled integers, since their representation typically consists of an integer
representing a multiple of the fixed delta.  

It appears that at the moment, Dwarf provides no way to represent such
types.  Ideally, we would like to propose the addition of a standard
DW_AT_scaling attribute.  Failing that, we'd appreciate any advice on
the right formulation for a vendor-supplied attribute.

The tricky part is that this particular attribute does not lend itself to
representation by a single integer.  A ratio of two integers would work, 
but that would seem to require two attributes, which seems inelegant.  
My only other thought is a string containing a fraction, as in
"1/1024".  That does the job, although it seems kludgy.  

Comments appreciated.

Paul Hilfinger
AdaCore




From brender  Tue Jun 28 09:49:09 2005
From: brender (Ron 603-884-2088)
Date: Tue Jun 28 09:49:09 2005
Subject: [Dwarf-discuss] Encoding fixed-point types
Message-ID: <05062809391323@gemevn.zko.dec.com>

Paul Hilfinger wrote:
>The Ada language provides fixed-point types, defined to represent a set
>of rational numbers consisting of a lower bound added to multiples
>of some fixed real increment or delta.   They are sometimes called
>scaled integers, since their representation typically consists of an integer
>representing a multiple of the fixed delta.  
>
>It appears that at the moment, Dwarf provides no way to represent such
>types.  Ideally, we would like to propose the addition of a standard
>DW_AT_scaling attribute.  Failing that, we'd appreciate any advice on
>the right formulation for a vendor-supplied attribute.
>
>The tricky part is that this particular attribute does not lend itself to
>representation by a single integer.  A ratio of two integers would work, 
>but that would seem to require two attributes, which seems inelegant.  
>My only other thought is a string containing a fraction, as in
>"1/1024".  That does the job, although it seems kludgy.  

Take a look at Issue 020401.1 in

  http://dwarf.freestandards.org/ShowIssue.php?issue=020401.1&type=closed

Don't be put off by the title which refers to COBOL data types.
It does include fixed point types with binary, decimal or arbitrary
"small" (inspired by Ada) scale factors. I think it covers what you
seek.

This item was officially adopted very recently.

Ron




From todd.allen  Tue Jun 28 09:59:07 2005
From: todd.allen (Todd Allen)
Date: Tue Jun 28 09:59:07 2005
Subject: [Dwarf-discuss] Encoding fixed-point types
In-Reply-To: <20050628063809.4E5A897BF@nile.gnat.com>
References: <20050628063809.4E5A897BF@nile.gnat.com>
Message-ID: <20050628135830.GA21996@toad.ccur.com>

On Tue, Jun 28, 2005 at 02:38:09AM -0400, Paul Hilfinger wrote:
> 
> The Ada language provides fixed-point types, defined to represent a set
> of rational numbers consisting of a lower bound added to multiples
> of some fixed real increment or delta.   They are sometimes called
> scaled integers, since their representation typically consists of an integer
> representing a multiple of the fixed delta.  
> 
> It appears that at the moment, Dwarf provides no way to represent such
> types.  Ideally, we would like to propose the addition of a standard
> DW_AT_scaling attribute.  Failing that, we'd appreciate any advice on
> the right formulation for a vendor-supplied attribute.
> 
> The tricky part is that this particular attribute does not lend itself to
> representation by a single integer.  A ratio of two integers would work, 
> but that would seem to require two attributes, which seems inelegant.  
> My only other thought is a string containing a fraction, as in
> "1/1024".  That does the job, although it seems kludgy.  
> 

This issue was addressed recently by the Dwarf 3 Workgroup.  Although
the issue was titled "Cobol Data Types".  The COBOL additions were
augmented slightly with a DW_AT_small attribute to support Ada.  See
the following issue for details:

   http://dwarf.freestandards.org/ShowIssue.php?issue=020401.1&type=closed

The CPQ's have been removed from all the attributes and definitions.
They were a remnant from when this was a Compaq specification.

The additions there don't really support a rational small.  At the time we
were working on the issue, the only Ada vendor involved was Concurrent, and
we didn't feel the need for it.  But if you do, I would suggest that you use
the DW_AT_small and then define something like a new DW_TAG_rational_constant
with DW_AT_numerator and DW_AT_denominator.

Also, I'd like to mention that we at Concurrent have a reasonably extensive
set of vendor extensions for Ada.  We proposed making it available for
inclusion into Dwarf 3 several years ago, but at that time, there were no
other Ada vendors involved in Dwarf 3, and so there was no interest.
Actually, we also made an early draft available to Gary Funck in '94, who I
believe was working on GNAT's debug facilities then.  He indicated that GNAT
was going a different route with separate debug tables outside the normal
debug formats.  Anyway, recently, we became aware that DDCI has a competing
set of vendor extensions.  If, from your recent involvement on the Dwarf
mailing lists, we can assume that GNAT has defined or is interested in
defining yet another set of extensions for Ada, perhaps it would be wise for
all of us to coordinate.

-- 
Todd Allen
Concurrent Computer Corporation



From jimb  Tue Jun 28 13:46:36 2005
From: jimb (Jim Blandy)
Date: Tue Jun 28 13:46:36 2005
Subject: [Dwarf-discuss] Isn't DW_OP_piece a location expression operator? 
Message-ID: <vt264vys7ii.fsf@zenia.home>


I'd like to suggest an editorial change to the spec.

DW_OP_piece is currently defined in the section on "Dwarf
expressions", not in the section on "Location Descriptions".  However,
DW_OP_piece doesn't compute a value to be left on the stack; it's only
useful in describing (a piece of) a larger value's location.

I think the definition of DW_OP_piece should be moved into the
"Location Descriptions" section, after the definitions of DW_OP_reg0
and friends.




From Keith.Walker  Wed Jun 29 05:57:04 2005
From: Keith.Walker (Keith Walker)
Date: Wed Jun 29 05:57:04 2005
Subject: [Dwarf-discuss] DW_TAG_condition
Message-ID: <DD2D1CDF962D7346A5B0E5EE9CA3612704F0DB5B@ZIPPY.Emea.Arm.com>

In the June 14, 2005 (Draft 9.3) DWARF3 Spec.:

The new tag DW_TAG_condition is missing from Figure 17, Tag encodings.



Keith Walker, Principle Engineer.
ARM Ltd. Phone: +44 1628 427732

This e-mail message is intended for the addressee(s) only and may
contain information that is the property of, and/or subject to a
confidentiality agreement between the intended recipient(s), their
organisation and/or the ARM Group of Companies. If you are not an
intended recipient of this e-mail message, you should not read, copy,
forward or otherwise distribute or further disclose the information in
it; misuse of the contents of this e-mail message may violate various
laws in your state, country or jurisdiction. If you have received this
e-mail message in error, please contact the originator of this e-mail
message via e-mail and delete all copies of this message from your
computer or network, thank you.
 



From hilfingr  Wed Jun 29 06:43:38 2005
From: hilfingr (Paul Hilfinger)
Date: Wed Jun 29 06:43:38 2005
Subject: [Dwarf-discuss] Encoding fixed-point types
In-Reply-To: <20050628135830.GA21996@toad.ccur.com> (message from Todd Allen
	on Tue, 28 Jun 2005 07:58:31 -0600)
References: <20050628063809.4E5A897BF@nile.gnat.com>
	<20050628135830.GA21996@toad.ccur.com>
Message-ID: <20050629104330.5CE04960F@nile.gnat.com>


> This issue was addressed recently by the Dwarf 3 Workgroup.  Although
> the issue was titled "Cobol Data Types".  The COBOL additions were
> augmented slightly with a DW_AT_small attribute to support Ada.  See
> the following issue for details:

>    http://dwarf.freestandards.org/ShowIssue.php?issue=020401.1&type=closed


Thanks for your (and Ron's) response.

> The additions there don't really support a rational small.  At the time we
> were working on the issue, the only Ada vendor involved was Concurrent, and
> we didn't feel the need for it.  But if you do, I would suggest that you use
> the DW_AT_small and then define something like a new DW_TAG_rational_constant
> with DW_AT_numerator and DW_AT_denominator.

The lack of rational constants, alas, would seem to limit the generality of 
the supported 'Small values.  I observe that such a facility would also give
a way to represent Ada named numbers.  

Are the vendor extensions for Ada that you mention publicly available?

Thanks.

P. Hilfinger



From brender  Wed Jun 29 09:46:24 2005
From: brender (Ron 603-884-2088)
Date: Wed Jun 29 09:46:24 2005
Subject: [Dwarf-discuss] DW_TAG_condition
Message-ID: <05062909422345@gemevn.zko.dec.com>

Keith Walker wrote:
>In the June 14, 2005 (Draft 9.3) DWARF3 Spec.:
>
>The new tag DW_TAG_condition is missing from Figure 17, Tag encodings.

Oops (& blush). Fixed...

Thanks,
Ron




From drow  Wed Jun 29 09:58:16 2005
From: drow (Daniel Jacobowitz)
Date: Wed Jun 29 09:58:16 2005
Subject: [Dwarf-discuss] DW_TAG_condition
In-Reply-To: <05062909422345@gemevn.zko.dec.com>
References: <05062909422345@gemevn.zko.dec.com>
Message-ID: <20050629135806.GA1686@nevyn.them.org>

On Wed, Jun 29, 2005 at 09:42:23AM -0400, Ron 603-884-2088 wrote:
> Keith Walker wrote:
> >In the June 14, 2005 (Draft 9.3) DWARF3 Spec.:
> >
> >The new tag DW_TAG_condition is missing from Figure 17, Tag encodings.
> 
> Oops (& blush). Fixed...

Where are current drafts available?  dwarf.freestandards.org doesn't
appear to have anything past Draft 9 (Sep. 2003).

-- 
Daniel Jacobowitz
CodeSourcery, LLC



From todd.allen  Wed Jun 29 11:12:51 2005
From: todd.allen (Todd Allen)
Date: Wed Jun 29 11:12:51 2005
Subject: [Dwarf-discuss] Encoding fixed-point types
In-Reply-To: <20050629104330.5CE04960F@nile.gnat.com>
References: <20050628063809.4E5A897BF@nile.gnat.com>
	<20050628135830.GA21996@toad.ccur.com>
	<20050629104330.5CE04960F@nile.gnat.com>
Message-ID: <20050629151214.GA4691@toad.ccur.com>

> The lack of rational constants, alas, would seem to limit the generality of 
> the supported 'Small values.  I observe that such a facility would also give
> a way to represent Ada named numbers.  

Well, without them things aren't perfect.  But providing smalls as
double-precision floating-point is pretty good.  And likewise with named
numbers.  And it saves debuggers from having to support abitrary-length
integers.  But I certainly wouldn't object to a new DW_TAG_rational_constant
that provided perfect representations.

> Are the vendor extensions for Ada that you mention publicly available?

Yes and no.  I have permission to distibute Concurrent's, but it isn't
anywhere that's easy to reach at the moment.  I'll send you a copy in a
subsequent email (to keep the mailing list bandwidth low).

Michael Eager is planning to place DDC-I's spec on the Dwarf 3 website.  And
I'll be sending him a copy of Concurrent's spec to go in the same place.

-- 
Todd Allen
Concurrent Computer Corporation



