From nickc@redhat.com  Fri Jan  4 08:59:03 2008
From: nickc@redhat.com (Nick Clifton)
Date: Fri, 04 Jan 2008 08:59:03 +0000
Subject: [Dwarf-Discuss] Inconsistency in DWARF length escape codes
Message-ID: <477DF557.1060300@redhat.com>

Hi Guys,

   There appears to be an inconsistency in the DWARF3 specification for the 
range of values that can be used as escape codes in the initial 4-byte length 
field of some headers:

   In section 7.2.2 (Initial Length Values) on page 120 of the DWARF3 spec 
(published Dec 20, 2005 and downloaded from http://dwarfstd.org) it says:

     "In an initial length field, the values 0xfffffff0 through
      0xffffffff are reserved by DWARF to indicate some form of
      extension relative to DWARF Version 2; such values must
      not be interpreted as a length field."

Note that the start value has seven 'f's and only one 0.  On the next page 
however (Section 7.4 32-Bit and 64-Bit DWARF Formats) in item 1 it says:

     "In the 32-bit DWARF format, an initial length field (see
      Section 7.2.2) is an unsigned 32-bit integer (which must
      be less than 0xffffff00);"

This time the reserved value has six 'f's and two 0's.  This smaller value is 
also referred to in Section 7.5.1, Section 7.19 and Section 7.20.

It would appear that Section 7.2.2 contains a typo and that the lower reserved 
value ought to be 0xffffff00.   On the other hand is there really a need for 
256 escape codes ?  Maybe the other sections are wrong and their lower limits 
should be changed to 0xfffffff0 ?

What do you think ?

Cheers
   Nick



From eager@eagercon.com  Fri Jan  4 18:48:02 2008
From: eager@eagercon.com (Michael Eager)
Date: Fri, 04 Jan 2008 10:48:02 -0800
Subject: [Dwarf-Discuss] Inconsistency in DWARF length escape codes
In-Reply-To: <477DF557.1060300@redhat.com>
References: <477DF557.1060300@redhat.com>
Message-ID: <477E7F62.7050108@eagercon.com>

Nick Clifton wrote:
> Hi Guys,
> 
>    There appears to be an inconsistency in the DWARF3 specification for the 
> range of values that can be used as escape codes in the initial 4-byte length 
> field of some headers:
> 
>    In section 7.2.2 (Initial Length Values) on page 120 of the DWARF3 spec 
> (published Dec 20, 2005 and downloaded from http://dwarfstd.org) it says:
> 
>      "In an initial length field, the values 0xfffffff0 through
>       0xffffffff are reserved by DWARF to indicate some form of
>       extension relative to DWARF Version 2; such values must
>       not be interpreted as a length field."
> 
> Note that the start value has seven 'f's and only one 0.  On the next page 
> however (Section 7.4 32-Bit and 64-Bit DWARF Formats) in item 1 it says:
> 
>      "In the 32-bit DWARF format, an initial length field (see
>       Section 7.2.2) is an unsigned 32-bit integer (which must
>       be less than 0xffffff00);"
> 
> This time the reserved value has six 'f's and two 0's.  This smaller value is 
> also referred to in Section 7.5.1, Section 7.19 and Section 7.20.
> 
> It would appear that Section 7.2.2 contains a typo and that the lower reserved 
> value ought to be 0xffffff00.   On the other hand is there really a need for 
> 256 escape codes ?  Maybe the other sections are wrong and their lower limits 
> should be changed to 0xfffffff0 ?
> 
> What do you think ?

I think that you found a typo.  The values should all be the same.
(It also points out that the DWARF standard should have only one place
where each value is defined.)

I don't recall the rationale for the range of reserved values.  But
I think that your question about whether 16 reserved values are adequate
is reasonable.  I don't see a need for more.

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



From fche@redhat.com  Fri Jan  4 21:28:47 2008
From: fche@redhat.com (Frank Ch. Eigler)
Date: Fri, 4 Jan 2008 16:28:47 -0500
Subject: [Dwarf-Discuss] PROPOSAL: Constant expressions in location lists
Message-ID: <20080104212847.GD6849@redhat.com>

Hi -

I just joined the list to rescussitate an old thread from June last
year [1].  I work on the systemtap project, and we are avid consumers
of DWARF data accompanying highly optimized binaries.  I bring it up
because we are starting to encounter real-world cases where variables
are optimized away from addressable locations, but can nevertheless be
readily rematerialized for debugging purposes.  Having a
DW_OP_computed_value (or extension of DW_OP_implicit_value) of the
sort Roland proposed would be a good fit to expose this data.

- FChE

[1] http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/2007-June/000483.html



From davea42@earthlink.net  Sat Jan  5 17:19:58 2008
From: davea42@earthlink.net (David Anderson)
Date: Sat, 05 Jan 2008 09:19:58 -0800
Subject: [Dwarf-Discuss] Inconsistency in DWARF length escape codes
In-Reply-To: <477DF557.1060300@redhat.com>
References: <477DF557.1060300@redhat.com>
Message-ID: <477FBC3E.3000403@earthlink.net>

Nick Clifton wrote:
> Hi Guys,
>
>    There appears to be an inconsistency in the DWARF3 specification for the 
> range of values that can be used as escape codes in the initial 4-byte length 
> field of some headers:
>   
M. Eager's observations are correct.

It is a typo.  My original intent was to allow 16 escape values
on the basis it was no more of a problem
for producers and consumers than allowing 1 value.

I had no specific meaning in mind for the 'other 15' values
than 'just in case it turns out to be useful'.

Only one escape value has a specific meaning, the other 15
are therefore undefined .

DavidAnderson





From jimb@red-bean.com  Sun Jan  6 07:29:04 2008
From: jimb@red-bean.com (Jim Blandy)
Date: Sat, 5 Jan 2008 23:29:04 -0800
Subject: [Dwarf-Discuss] PROPOSAL: Constant expressions in location lists
In-Reply-To: <20080104212847.GD6849@redhat.com>
References: <20080104212847.GD6849@redhat.com>
Message-ID: <8f2776cb0801052329m21b54d6ftf6b5223ae71ab54b@mail.gmail.com>

On Jan 4, 2008 1:28 PM, Frank Ch. Eigler <fche at redhat.com> wrote:
> I just joined the list to rescussitate an old thread from June last
> year [1].  I work on the systemtap project, and we are avid consumers
> of DWARF data accompanying highly optimized binaries.  I bring it up
> because we are starting to encounter real-world cases where variables
> are optimized away from addressable locations, but can nevertheless be
> readily rematerialized for debugging purposes.  Having a
> DW_OP_computed_value (or extension of DW_OP_implicit_value) of the
> sort Roland proposed would be a good fit to expose this data.

When you say "rematerialized for debugging purposes", do you mean that
the value is a constant known at build time, or do you mean that it
can be computed from the current state of the program, even though the
variable has no location allocated to it at the moment?

The DW_OP_constant_value suggestion would help with the former, but
not the latter.  (What you wrote makes me think you have the latter in
mind.)



From roland@redhat.com  Sun Jan  6 07:59:26 2008
From: roland@redhat.com (Roland McGrath)
Date: Sat,  5 Jan 2008 23:59:26 -0800 (PST)
Subject: [Dwarf-Discuss] PROPOSAL: Constant expressions in location lists
In-Reply-To: Jim Blandy's message of  Saturday, 5 January 2008 23:29:04 -0800
	<8f2776cb0801052329m21b54d6ftf6b5223ae71ab54b@mail.gmail.com>
References: <20080104212847.GD6849@redhat.com>
	<8f2776cb0801052329m21b54d6ftf6b5223ae71ab54b@mail.gmail.com>
Message-ID: <20080106075926.E588F26F9A3@magilla.localdomain>

> When you say "rematerialized for debugging purposes", do you mean that
> the value is a constant known at build time, or do you mean that it
> can be computed from the current state of the program, even though the
> variable has no location allocated to it at the moment?

I believe he was referring to the general case, i.e. the latter.

> The DW_OP_constant_value suggestion would help with the former, but
> not the latter.  (What you wrote makes me think you have the latter in
> mind.)

Frank referred to my proposal in http://lists.dwarfstd.org/htdig.cgi/dwarf-discuss-dwarfstd.org/2007-May/000478.html

This handles the general case by computing values (or values of pieces)
with arbitrary DWARF expressions.  Compile-time constants are a degenerate
case where those expressions use only const*/lit* ops.


Thanks,
Roland



From jimb@red-bean.com  Sun Jan  6 09:17:37 2008
From: jimb@red-bean.com (Jim Blandy)
Date: Sun, 6 Jan 2008 01:17:37 -0800
Subject: [Dwarf-Discuss] PROPOSAL: Constant expressions in location lists
In-Reply-To: <20080106075926.E588F26F9A3@magilla.localdomain>
References: <20080104212847.GD6849@redhat.com>
	<8f2776cb0801052329m21b54d6ftf6b5223ae71ab54b@mail.gmail.com>
	<20080106075926.E588F26F9A3@magilla.localdomain>
Message-ID: <8f2776cb0801060117t415f623do3dc2a75d6c78868@mail.gmail.com>

On Jan 5, 2008 11:59 PM, Roland McGrath <roland at redhat.com> wrote:
> > The DW_OP_constant_value suggestion would help with the former, but
> > not the latter.  (What you wrote makes me think you have the latter in
> > mind.)
>
> Frank referred to my proposal in http://lists.dwarfstd.org/htdig.cgi/dwarf-discuss-dwarfstd.org/2007-May/000478.html
>
> This handles the general case by computing values (or values of pieces)
> with arbitrary DWARF expressions.  Compile-time constants are a degenerate
> case where those expressions use only const*/lit* ops.

I misread that proposal, I guess.

Are you very sure you want to use DWARF expressions to compute
source-language values?  To be honest, it doesn't seem like a great
idea to me.  I don't know what kinds of values your compiler (GCC, I
assume) could potentially need to express this way, but in the general
case those will be some gnarly DWARF expressions to produce.  It seems
to me the problem's not less hard than targeting a new architecture.
We could add an operator analogous to DW_OP_pick that stores a value
at a given depth on the stack, to get random access to the stack; that
might make code generation a bit easier.  I suppose you could use
DW_OP_call* to call "library" expressions from a library to do things
like long long division.

But this seems like a case where the compiler folks (i.e. you) are
offering to bend over backwards to make only a minimal change to the
DWARF standard, but the result will be something difficult for
producers to actually emit.

It would seem much cleaner to simply represent source language
expressions as DIE trees.  Every source-level debugger already has the
machinery to evaluate those.  Their semantics are as well-defined as
the language itself.

In what form does GCC have these rematerializeable values?  As source
expressions or something close to that?  Or are they in RTL (GCC's
machine-level intermediate language, for folks who don't know GCC) so
producing DWARF expressions is no worse than targeting a new processor
back end?



From aoliva@redhat.com  Sun Jan  6 10:03:15 2008
From: aoliva@redhat.com (Alexandre Oliva)
Date: Sun, 06 Jan 2008 08:03:15 -0200
Subject: [Dwarf-Discuss] PROPOSAL: Constant expressions in location lists
In-Reply-To: <20080106075926.E588F26F9A3@magilla.localdomain> (Roland
	McGrath's message of "Sat\, 5 Jan 2008 23\:59\:26 -0800 \(PST\)")
References: <20080104212847.GD6849@redhat.com>
	<8f2776cb0801052329m21b54d6ftf6b5223ae71ab54b@mail.gmail.com>
	<20080106075926.E588F26F9A3@magilla.localdomain>
Message-ID: <orir278e58.fsf@oliva.athome.lsd.ic.unicamp.br>

On Jan  6, 2008, Roland McGrath <roland at redhat.com> wrote:

>> When you say "rematerialized for debugging purposes", do you mean that
>> the value is a constant known at build time, or do you mean that it
>> can be computed from the current state of the program, even though the
>> variable has no location allocated to it at the moment?

> I believe he was referring to the general case, i.e. the latter.

Yep, I talked to him about this just before he posted his e-mail.
Also, on Dec 27, not knowing you'd already started discussing this
here, I submitted an extension proposal at
http://dwarfstd.org/Comment.php, that Michael Eager has already
acknowledged but hasn't added to the Open Issues page yet.

In that proposal, I use DW_OP_value as the operator name.

Frank suggested an alternate representation, that might be less
intrusive and more backward-compatible.  Something along the lines of
DW_AT_value, that could hold a loclistptr, but in which the
expressions would represent values, rather than locations.  (We can't
just reuse DW_AT_const_value, because adding loclistptr to its
available classes would change the meaning of DW_FORM_data[48] :-(

When both DW_AT_value and DW_AT_location are present, they would add,
rather than override each other, just like overlapping ranges in
DW_AT_location add up.  So, at the same PC, one could have multiple
locations for a piece of a variable, and multiple value expressions as
well.  The effect would be equivalent to that of adding a deref to
each piece of each DW_AT_location location expression that mentions a
memory address, except that DW_AT_location locations are assumed to be
modifiable (and thus exclusively assigned to the mentioned variable),
whereas a dereferenced address or a register in a DW_AT_value is
expected to be non-modifiable or shared.


This reminds me of one doubt I have.  Consider a variable that
represents a struct-typed object.  If the compiler scalarizes it, and
each member becomes an independent implementation variable, must the
compiler emit a separate location list entry for the entire source
variable every time any of the members change location, or can it use
separate entries with DW_OP_nop for all but one of the pieces, and
rely on overlapping ranges for the debugger to put it all together?

I.e., consider

struct { int x, y; };

Could a representation such as:

  [L0,L1) [nop] DW_OP_piece 4 DW_OP_reg1 DW_OP_piece 4
  [L1,L2) DW_OP_reg0 DW_OP_piece 4 DW_OP_reg1 DW_OP_piece 4
  [L2,L3) DW_OP_reg0 DW_OP_piece 4 [nop] DW_OP_piece 4

be shortened to:

  [L0,L2) [nop] DW_OP_piece 4 DW_OP_reg1 DW_OP_piece 4
  [L1,L3) DW_OP_reg0 DW_OP_piece 4 [nop] DW_OP_piece 4

this becomes even more important if any of the pieces is
simultaneously available in more than one location (say, its stack
slot and a register it is live in throughout a loop).


BTW, It might have been useful to have accepted negative operands to
DW_OP_piece to cover these cases, as in:

  DW_OP_reg0 DW_OP_piece 4 DW_OP_piece -4 DW_OP_fbreg -60 DW_OP_piece 4

or perhaps we could introduce DW_OP_both:

  DW_OP_reg0 DW_OP_fbreg -60 DW_OP_both DW_OP_piece 4

but this doesn't work all that well with say a bit field partially
scalarized into registers that retains memory backstore, and it
doesn't work at all for DW_OP_bit_piece, should the second operand of
DW_OP_bit_piece have to vary for each component (e.g. if we were to
represent various portions of the memory backstore as bit-fields
themselves)

So perhaps something like DW_OP_overlap, with a bit-count, would be
best:

  DW_OP_reg0 DW_OP_piece 4 DW_OP_overlap 32 DW_OP_fbreg -60 DW_OP_piece 4

DW_OP_overlap might accept negative values, mainly for bit-padding,
avoiding the need for DW_OP_bit_piece's useless second operand, both
in backtracking and in advancing the bit position, as in:

  DW_OP_reg0 DW_OP_bit_piece 15 0 \
  DW_OP_overlap 15 \
  DW_OP_fbreg -52 DW_OP_bit_piece 15 0 \
  DW_OP_reg1 DW_OP_bit_piece 15 0 \
  DW_OP_overlap 15 \
  DW_OP_fbreg -52 DW_OP_bit_piece 15 15 \
  DW_OP_overlap -2 \
  ...

which would be better represented as

  DW_OP_reg0 DW_OP_bit_piece 15 0 \
  DW_OP_reg1 DW_OP_bit_piece 15 0 \
  DW_OP_overlap 30 \
  DW_OP_fbreg -52 DW_OP_piece 4 \
  ...

But I'm not sure about the wisdom of introducing such explicit
backward-incompatible overlap mechanisms, if empty DW_OP_pieces can be
taken from overlapping ranges.  It can be more compact, for sure, but
it amounts to a lot of complexity and redundancy as well.
  

> Frank referred to my proposal in http://lists.dwarfstd.org/htdig.cgi/dwarf-discuss-dwarfstd.org/2007-May/000478.html

> This handles the general case by computing values (or values of pieces)
> with arbitrary DWARF expressions.  Compile-time constants are a degenerate
> case where those expressions use only const*/lit* ops.

http://dwarfstd.org/ShowIssue.php?issue=070512.1&type=closed appears
to indicate that DW_OP_implicit_value, that you mentioned in your
e-mail, was actually accepted in a far more limited way, that only
supports literal constant values.

Unfortunately, there's an error in
http://dwarfstd.org/Issues.php?type=closed because, just before the
070512.1 issue, there are two issues numbered 070426.2, and the second
of them, that appears to be the one that introduced
DW_OP_implicit_value, is not trivially accessible.

Its correct number is 070426.1, and it should link to
http://dwarfstd.org/ShowIssue.php?issue=070426.1&type=closed

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}



From roland@redhat.com  Sun Jan  6 12:36:35 2008
From: roland@redhat.com (Roland McGrath)
Date: Sun,  6 Jan 2008 04:36:35 -0800 (PST)
Subject: [Dwarf-Discuss] PROPOSAL: Constant expressions in location lists
In-Reply-To: Jim Blandy's message of  Sunday, 6 January 2008 01:17:37 -0800
	<8f2776cb0801060117t415f623do3dc2a75d6c78868@mail.gmail.com>
References: <20080104212847.GD6849@redhat.com>
	<8f2776cb0801052329m21b54d6ftf6b5223ae71ab54b@mail.gmail.com>
	<20080106075926.E588F26F9A3@magilla.localdomain>
	<8f2776cb0801060117t415f623do3dc2a75d6c78868@mail.gmail.com>
Message-ID: <20080106123635.E203626F9A4@magilla.localdomain>

I am somewhat confused by your reference to "source-language values".
That's not how I think about them.  I'd say they are target machine
values, i.e. raw byte/bit granularity data, as a value supplied by
DW_AT_const_value is, and as the values whose locations are described by
location expressions are.  No notion of "value" in DWARF deals in
source-language terms.  Rather, the values DWARF describes are target
machine values, bit-for-bit as would appear in memory/registers.  It's
the source-language constructs (subprogram, variable, etc.) and types
DWARF describes that both lead you to those values and tell you how to
interpret them in source-language terms (e.g. via data_member_location).

I am particularly confused by your reference to DIE trees.  These
describe declarations, and do not represent computations in any way I
understand.  They are our generic tree format of course, so you could
certainly define a whole new set of tags to describe expression trees.
But that seems rather far out in left field.  Am I misunderstanding you?

I work on the consumer side of the equation, myself (and I'm habitually
anal about specifications for corner cases).  So my own focus is on what
the format means and how a consumer can interpret it to cover every
possible expressible truth about the actual code generated that a
compiler might one day be clever enough both to claim and to generate
code that makes true.  That doesn't mean I expect any compiler any day
soon to produce any of the very complicated cases.  Indeed, DWARF
explicitly never speaks to expectations about the quality and detail of
the information a compiler produces, just about precisely what claims
it's expressing when it emits certain data in DWARF formats.

It is indeed true that in the general case producing expressions is
tantamount to code generation for DWARF's primitive stack machine.
But let's look at how this will really come up.  This is a value cell
that the compiler optimized away but still groks the derivation of.
Usually that's either because it's a compile-time constant, or because
it was CSE'd with another value already on hand at this point in the
computation.  In the latter case, it's most likely a small amount of
arithmetic on some registers or stack slots.  Something real
complicated is not so likely to have been optimized away.  It could
indeed be that something as hairy to compute as division of larger
than target word size could be easily CSE'd in this fashion (or
e.g. just any FP arithmetic at all).  Then indeed a really hard-core
producer could emit enormous DWARF expression subroutine libraries to
call from its expressions.  Or it could just punt on these hard cases,
(just like it now punts on this whole class of case that can't be
represented anyway).  The common case is:

	static inline void foo(long *p) { bar(*p); }
	void baz(long s[99], long i) { foo(&s[i]); s[0] = 1; }
	--->
	baz:
		pushq	%rbx
		movq	%rdi, %rbx
		movq	(%rdi,%rsi,8), %rdi
		xorl	%eax, %eax
		call	bar
		movq	$1, (%rbx)
		popq	%rbx
		ret

"p" has been optimized away.  But its location could be given as:

	DW_OP_lit8 DW_OP_reg4 DW_OP_mul DW_OP_reg3 DW_OP_plus DW_OP_value

This one is simple to produce, because it had to be simple enough to
be expressed with the machine's addressing modes to have been
optimized this way.  I don't really know the compiler internals, but I
assume it has RTL now and will one day have some tree form instead.
If it's RTL for an integer value computation without side effects (and
not wider than target word size), then that RTL expression tree
flattens into DWARF ops (usually using a value stack no more than two
deep), in a very straightforward way.


Thanks,
Roland



From roland@redhat.com  Sun Jan  6 16:22:14 2008
From: roland@redhat.com (Roland McGrath)
Date: Sun,  6 Jan 2008 08:22:14 -0800 (PST)
Subject: [Dwarf-Discuss] PROPOSAL: Constant expressions in location lists
In-Reply-To: Alexandre Oliva's message of  Sunday,
	6 January 2008 08:03:15 -0200
	<orir278e58.fsf@oliva.athome.lsd.ic.unicamp.br>
References: <20080104212847.GD6849@redhat.com>
	<8f2776cb0801052329m21b54d6ftf6b5223ae71ab54b@mail.gmail.com>
	<20080106075926.E588F26F9A3@magilla.localdomain>
	<orir278e58.fsf@oliva.athome.lsd.ic.unicamp.br>
Message-ID: <20080106162214.D551326F9A4@magilla.localdomain>

> In that proposal, I use DW_OP_value as the operator name.

I like that name.  There's also something to be said for
DW_OP_val_expression given DW_CFA_val_expression.

> Frank suggested an alternate representation, that might be less
> intrusive and more backward-compatible.  Something along the lines of
> DW_AT_value, that could hold a loclistptr, but in which the
> expressions would represent values, rather than locations.  

I see the benefit of that approach, in that it only adds something new
an old consumer can ignore entirely, and not a new DWARF opcode value
that it doesn't know how to skip over in a location expression.

> (We can't just reuse DW_AT_const_value, because adding loclistptr to its
> available classes would change the meaning of DW_FORM_data[48] :-(

Indeed, it might be nice if we'd had DW_FORM_locp a la strp from the beginning.

The apparent reason for some people's preference for DW_OP_constant_value
is its simplicity for new consumers dealing with the constant-value case.
If you wanted to get that in the compatibly-parallel style of DW_AT_value,
you could add a DW_AT_const_value_loclist (since DW_AT_const_value can't
compatibly be overloaded, as you say) whose list entries are not actually
expressions but are blocks of constant data bytes.  (This doesn't really
appeal to me, especially since it doesn't handle pieces.  But that didn't
seem to be much on the minds of those proposing DW_OP_constant_value in the
first place either.  Both this and DW_OP_constant_value are better than
DW_OP_value/DW_AT_value for handling very large constant blocks.)

> When both DW_AT_value and DW_AT_location are present, they would add,
> rather than override each other, just like overlapping ranges in
> DW_AT_location add up.  

At first blush I found this suggestion a more onerous and unnatural way to
represent it than DW_OP_value.  It does make it harder for a human to read.
But, given overlapping location list entries where some of the multiple
applicable expressions are composite, the letter of the existing spec
permits one composite to have a zero-expressions (unavailable) piece
covering a range of the whole for which another composite has a nonempty
expression (available location).  So it could be read that a robust
consumer already ought to be merging the alternate location expressions and
then taking the "best" alternative for each byte when subsetting.  For a
consumer organized that way, it is not much of a stretch to merge alternate
location expressions and/or value expressions and/or constant value blocks.

> This reminds me of one doubt I have.  Consider a variable that
> represents a struct-typed object.  If the compiler scalarizes it, and
> each member becomes an independent implementation variable, must the
> compiler emit a separate location list entry for the entire source
> variable every time any of the members change location, or can it use
> separate entries with DW_OP_nop for all but one of the pieces, and
> rely on overlapping ranges for the debugger to put it all together?

DW_OP_nop is not used for this.  AFAICT an expression containing just
DW_OP_nop is invalid by the letter of the spec.  What I think you mean is
an empty location expression before a DW_OP_piece, which is what is
specified to mean "this piece not available here".  (I don't know what
DW_OP_nop is used for at all, in fact.  The only thing I can think of is
adjusting the alignment before a DW_OP_addr so the address after it would
be naturally aligned for relocation or something.)

> Could a representation such as:
> 
>   [L0,L1) [nop] DW_OP_piece 4 DW_OP_reg1 DW_OP_piece 4
>   [L1,L2) DW_OP_reg0 DW_OP_piece 4 DW_OP_reg1 DW_OP_piece 4
>   [L2,L3) DW_OP_reg0 DW_OP_piece 4 [nop] DW_OP_piece 4
> 
> be shortened to:
> 
>   [L0,L2) [nop] DW_OP_piece 4 DW_OP_reg1 DW_OP_piece 4
>   [L1,L3) DW_OP_reg0 DW_OP_piece 4 [nop] DW_OP_piece 4

(Here I'm reading [nop] as nothing at all.)  As I said above, one can
indeed interpret the specification of overlapping location list entries
as expecting you to cope with this.  But as always DWARF just says what
it says and it doesn't say how smart the producers or consumers have to
be (it's a format spec, not a compiler-debugger interoperability
contract).  So fall back on Postel's Law.  I'll endeavor to write a
liberal consumer able to do the best possible with the shortest list.
But you won't be a conservative producer to do the latter in place of
the former.

Existing consumers I'm familiar with simply pick the first entry in the
location list matching the PC, and have abandoned any other location
expression but that one before they even consider slicing a composite.
So at L1 they will lose access to x or y if you use the shorter list.

> BTW, It might have been useful to have accepted negative operands to
> DW_OP_piece to cover these cases, as in:
> 
>   DW_OP_reg0 DW_OP_piece 4 DW_OP_piece -4 DW_OP_fbreg -60 DW_OP_piece 4

That's more compactly expressed by a variant of piece that takes two
parameters, size and offset (either overlap backwards, or absolute
offset from the start of this composite), as in:

	DW_OP_reg0 DW_OP_piece 4 DW_OP_fbreg -60 DW_OP_abs_piece 4 0

> But I'm not sure about the wisdom of introducing such explicit
> backward-incompatible overlap mechanisms, if empty DW_OP_pieces can be
> taken from overlapping ranges.  It can be more compact, for sure, but
> it amounts to a lot of complexity and redundancy as well.

It doesn't have to be too complex if you pick one new composition
operator that covers all the cases, and e.g. say that an expression
using the new one cannot intermix it with piece and bit_piece.  

Every new opcode is an incompatible addition.  An old consumer cannot
even parse the rest of the location expression, so it must reject the
whole expression.  (It cannot e.g. skip this piece from a composite.)
This is the big disadvantage of adding new expression opcodes vs adding
new attributes and tags, which old consumers just don't notice.  The

070426.1 addition is somewhat mitigated in this regard by being
specified as a singleton operator in an expression anyway.  If it were
used in a composite it would still cause an old consumer to reject the
whole composite.  But its simple use is basically as a special escape in
location list entries.

The location list overlap semantics have the nice feature that a
simple-minded consumer just doesn't notice there is something complex
going on (only uses the first match), rather than in a complex case
suddenly hitting a fancy operator it's not sophisticated enough even to
see how to ignore.  I like that aspect of the DW_AT_value approach too.

> http://dwarfstd.org/ShowIssue.php?issue=070512.1&type=closed appears
> to indicate that DW_OP_implicit_value, that you mentioned in your
> e-mail, was actually accepted in a far more limited way, that only
> supports literal constant values.

That was the original proposal, to which mine was the counter.  I can't
tell whether it's called DW_OP_implicit_value or DW_OP_constant_value,
since both are used in the "accepted" proposal text.  (DW_OP_const_value
would be the most consistent name given what it does and the precedent
of DW_AT_const_value.)

I've since come to dislike this proposal for reasons much more boring
than the rest of this discussion.  It is unlike all other DWARF
operations, which take 0-2 scalar parameters, while the new one takes a
block.  This makes it ill-suited to existing consumer APIs that decode
DWARF operation encodings into internal form.  


Thanks,
Roland



From eager@eagercon.com  Sun Jan  6 17:50:15 2008
From: eager@eagercon.com (Michael Eager)
Date: Sun, 06 Jan 2008 09:50:15 -0800
Subject: [Dwarf-Discuss] PROPOSAL: Constant expressions in location lists
In-Reply-To: <8f2776cb0801060117t415f623do3dc2a75d6c78868@mail.gmail.com>
References: <20080104212847.GD6849@redhat.com>	<8f2776cb0801052329m21b54d6ftf6b5223ae71ab54b@mail.gmail.com>	<20080106075926.E588F26F9A3@magilla.localdomain>
	<8f2776cb0801060117t415f623do3dc2a75d6c78868@mail.gmail.com>
Message-ID: <478114D7.7000009@eagercon.com>

Jim Blandy wrote:

> It would seem much cleaner to simply represent source language
> expressions as DIE trees.  Every source-level debugger already has the
> machinery to evaluate those.  Their semantics are as well-defined as
> the language itself.

Except for the evaluation of DWARF expressions, there are no semantics
defined in DWARF.  It's purely descriptive.

I don't know any way to describe source language expressions in DWARF.
DIEs can not describe source expressions, nor is there any way to
"evaluate" a DIE, whatever that may mean.

DWARF describes the mapping between source language features and
the resulting generated code.  None of the source language semantics
is described by DWARF.

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



From jimb@red-bean.com  Mon Jan  7 01:26:04 2008
From: jimb@red-bean.com (Jim Blandy)
Date: Sun, 6 Jan 2008 17:26:04 -0800
Subject: [Dwarf-Discuss] PROPOSAL: Constant expressions in location lists
In-Reply-To: <478114D7.7000009@eagercon.com>
References: <20080104212847.GD6849@redhat.com>
	<8f2776cb0801052329m21b54d6ftf6b5223ae71ab54b@mail.gmail.com>
	<20080106075926.E588F26F9A3@magilla.localdomain>
	<8f2776cb0801060117t415f623do3dc2a75d6c78868@mail.gmail.com>
	<478114D7.7000009@eagercon.com>
Message-ID: <8f2776cb0801061726w41ee8be5p3456f041a9ba157b@mail.gmail.com>

On Jan 6, 2008 9:50 AM, Michael Eager <eager at eagercon.com> wrote:
> Jim Blandy wrote:
>
> > It would seem much cleaner to simply represent source language
> > expressions as DIE trees.  Every source-level debugger already has the
> > machinery to evaluate those.  Their semantics are as well-defined as
> > the language itself.
>
> Except for the evaluation of DWARF expressions, there are no semantics
> defined in DWARF.  It's purely descriptive.
>
> I don't know any way to describe source language expressions in DWARF.
> DIEs can not describe source expressions, nor is there any way to
> "evaluate" a DIE, whatever that may mean.
>
> DWARF describes the mapping between source language features and
> the resulting generated code.  None of the source language semantics
> is described by DWARF.

My idea was so out in the weeds that Michael misunderstood it and
Roland assumed I couldn't possibly have meant that.  :) The smart
thing to say is obviously, "Uh, never mind."  But let me try again.

The problem here is that DWARF needs to be able to describe how to
compute values of variables that have been optimized out but could be
computed from the state of the program (at least some of the time).
There's no necessary restriction on what types of values a compiler
might be able to optimize out; in the most general case, the values to
be computed could be structures, large floating-point types, etc.  So
DWARF needs to be able to describe how to compute values with
arbitrary source types.

DWARF does have DWARF expressions, but their semantics were
deliberately restricted to computing address-sized values, to keep the
specification simple and focussed.  We're now considering using DWARF
expressions to compute (potentially) every type of value expressible
in the source language.

Following this approach, If the compiler had optimized out a
floating-point value, but knew how to recompute it if desired, and
wished to express this in DWARF, the compiler would need to produce a
DWARF expression that would yield the appropriate floating-point
value, in target format.

As Roland says, this can be done.  We can have massive collections of
DWARF expressions invoking each other with DW_OP_call* to carry out
IEEE double-precision floating-point arithmetic on the DWARF
expression stack.  And as Roland says, if the compiler finds this to
be too much trouble, then it needn't produce the information at all;
we're no worse off than we are now.

My thought was that the easiest way to have a debugger compute values
of potentially arbitrary type would be to use the evaluator for
source-language expressions that every source-level debugging tool
already has.  The debuggers have already implemented (say) IEEE
floating-point arithmetic, if that's what the target uses.  We would
extend DWARF with tags representing source language expression
operators (*, +, []) and literals ("foo", 1.0, 'c'), and have
compilers emit die trees representing the expression the debugger
should compute to rematerialize the value of the missing variable.

At first blush, this might seem like a horrible bloat of the DWARF
spec: would the spec have to describe (say) C's integral type
promotion rules for binary operators, the proper handling of 0 when it
appears as the second or third operand of a ?: expression, and so on?

But I don't think that, at least, is a problem.  It would be
sufficient for the DWARF standard to say, "Some attributes refer to
source-language expressions.  DWARF can encode source-language
expressions for languages X, Y, and Z.  For language X, here is how we
represent source expressions in DWARF:", and then list the
correspondence of X operators and DWARF tags.  There's no need for the
DWARF spec to describe the semantics of the operators at all: as long
as DWARF could faithfully convey the expression from producer to
consumer, along with the environment in which it was to be evaluated,
it would be up to the consumer to properly evaluate the expression.
As I say, most consumers already have evaluators for source-language
expressions anyway, and have dealt with the subtleties; we're just
adding a new way of representing such expressions.

At the moment, the DWARF spec uses generic tags like
DW_TAG_pointer_type for every supported language's pointer type, and
it's left to the producers and consumers how exactly to fit the
concepts in the language specification onto the set of tags provided
by DWARF.  At times this process has needed some clarification, but
it's worked well enough.  To carry this approach over to expressions,
DWARF would specify tags like DW_TAG_expr_multiply and
DW_TAG_expr_deference, describing each clearly enough to allow the
authors of Pascal consumers and producers to understand that the
latter tag is the right thing to use for Pascal's '^' operator, and to
allow a C developer to recognize it as unary '*'.

Perhaps this is "far out in left field".  But using DWARF expressions
for this would be a pretty serious extension of their
responsibilities, and in the non-trivial cases would result in exactly
the sort of ridiculous complexity (I think implementing floating-point
in DWARF expressions is ridiculous) that you'd expect from that.  We
would, in practice if not in the letter of the spec, be restricting
DWARF to supporting the easy cases.



From sabre@nondot.org  Mon Jan  7 02:23:54 2008
From: sabre@nondot.org (Chris Lattner)
Date: Sun, 6 Jan 2008 18:23:54 -0800
Subject: [Dwarf-Discuss] PROPOSAL: Constant expressions in location lists
In-Reply-To: <8f2776cb0801061726w41ee8be5p3456f041a9ba157b@mail.gmail.com>
References: <20080104212847.GD6849@redhat.com>
	<8f2776cb0801052329m21b54d6ftf6b5223ae71ab54b@mail.gmail.com>
	<20080106075926.E588F26F9A3@magilla.localdomain>
	<8f2776cb0801060117t415f623do3dc2a75d6c78868@mail.gmail.com>
	<478114D7.7000009@eagercon.com>
	<8f2776cb0801061726w41ee8be5p3456f041a9ba157b@mail.gmail.com>
Message-ID: <486AFFDB-5D00-4BAC-B3EE-EE072F0C3B29@nondot.org>


On Jan 6, 2008, at 5:26 PM, Jim Blandy wrote:

> At first blush, this might seem like a horrible bloat of the DWARF
> spec: would the spec have to describe (say) C's integral type
> promotion rules for binary operators, the proper handling of 0 when it
> appears as the second or third operand of a ?: expression, and so on?

Why would you want to encode it at the source level?  You just need  
the ability for the compiler to express how to compute it, which  
doesn't require source-level rules.  For example, instead of  
expressing all the semantics of C casts, you could have explicit sign  
extend, truncate, zero extend, etc operations, and have the compiler  
emit those instead.

In fact, this would be a better parity match with most compiler  
backends anyway.

-Chris



From eager@eagercon.com  Mon Jan  7 03:38:09 2008
From: eager@eagercon.com (Michael Eager)
Date: Sun, 06 Jan 2008 19:38:09 -0800
Subject: [Dwarf-Discuss] PROPOSAL: Constant expressions in location lists
In-Reply-To: <8f2776cb0801061726w41ee8be5p3456f041a9ba157b@mail.gmail.com>
References: <20080104212847.GD6849@redhat.com>	
	<8f2776cb0801052329m21b54d6ftf6b5223ae71ab54b@mail.gmail.com>	
	<20080106075926.E588F26F9A3@magilla.localdomain>	
	<8f2776cb0801060117t415f623do3dc2a75d6c78868@mail.gmail.com>	
	<478114D7.7000009@eagercon.com>
	<8f2776cb0801061726w41ee8be5p3456f041a9ba157b@mail.gmail.com>
Message-ID: <47819EA1.6010704@eagercon.com>

Jim Blandy wrote:
> The problem here is that DWARF needs to be able to describe how to
> compute values of variables that have been optimized out but could be
> computed from the state of the program (at least some of the time).

That is a relatively simple task, one dependent only on the
compiler's ability to describe how to compute the missing value.

> There's no necessary restriction on what types of values a compiler
> might be able to optimize out; in the most general case, the values to
> be computed could be structures, large floating-point types, etc.  So
> DWARF needs to be able to describe how to compute values with
> arbitrary source types.

No, you only need to be able to interpret the instructions given
by the compiler to compute a machine value.  This does not require
that a debugger have a source language interpreter, and in particular,
it doesn't require DWARF to be able to describe arbitrary source types.

> DWARF does have DWARF expressions, but their semantics were
> deliberately restricted to computing address-sized values, to keep the
> specification simple and focussed.  We're now considering using DWARF
> expressions to compute (potentially) every type of value expressible
> in the source language.

This seems to exaggerate the problem.  You don't need to compute
"every value expressible in the source".  Instead you need to compute
every value expressible in the machine.  Machines have a very narrow
range of types, usually two: binary integer and floating point.  And
it may not be necessary to even compute that range -- all you care
about is bit patterns.

> Following this approach, If the compiler had optimized out a
> floating-point value, but knew how to recompute it if desired, and
> wished to express this in DWARF, the compiler would need to produce a
> DWARF expression that would yield the appropriate floating-point
> value, in target format.

That's true, but it doesn't necessarily follow that DWARF expressions
need to perform floating point computations.

Let's say you had the following snippet of code:

     float pi(void) {
        float val = 3.14159;
        return val;
     }

A reasonable compiler would discard 'val' resulting in the debugger
giving a message saying that the value was not available.  To
reconstruct the value of this discarded variable, all you need to
do is generate the bit pattern which has this value: 0x400921fa.

> My thought was that the easiest way to have a debugger compute values
> of potentially arbitrary type would be to use the evaluator for
> source-language expressions that every source-level debugging tool
> already has.  The debuggers have already implemented (say) IEEE
> floating-point arithmetic, if that's what the target uses.  We would
> extend DWARF with tags representing source language expression
> operators (*, +, []) and literals ("foo", 1.0, 'c'), and have
> compilers emit die trees representing the expression the debugger
> should compute to rematerialize the value of the missing variable.
> 
> At first blush, this might seem like a horrible bloat of the DWARF
> spec: would the spec have to describe (say) C's integral type
> promotion rules for binary operators, the proper handling of 0 when it
> appears as the second or third operand of a ?: expression, and so on?
> 
> But I don't think that, at least, is a problem.  It would be
> sufficient for the DWARF standard to say, "Some attributes refer to
> source-language expressions.  DWARF can encode source-language
> expressions for languages X, Y, and Z.  For language X, here is how we
> represent source expressions in DWARF:", and then list the
> correspondence of X operators and DWARF tags.  There's no need for the
> DWARF spec to describe the semantics of the operators at all: as long
> as DWARF could faithfully convey the expression from producer to
> consumer, along with the environment in which it was to be evaluated,
> it would be up to the consumer to properly evaluate the expression.
> As I say, most consumers already have evaluators for source-language
> expressions anyway, and have dealt with the subtleties; we're just
> adding a new way of representing such expressions.

Conveying the environment in which the compilation occurs is the
big problem which you gloss over.  Hiding the complexities of
source language semantics with a bit of hand-waving creates the
problems of unclear specification which DWARF was designed to avoid.

You seem to be under the impression that it is easy to represent all
of the possible variations in translation which a compiler can perform
on a source language.  I'm familiar with compilers which, depending on
user options, can generate significantly different data structures,
requiring significantly different code to evaluate.  It's simply not
a matter saying "+" means DW_add, because the "+" may be operating on
wide variety of data types.

Consider a C++ statement "a = b + c".  How do you represent this
if a, b, and c may be various size scalars, vectors, or template
types with user defined operations?

You might say "everyone knows what an int is" but this is exactly
the implicit assumptions which caused problems in DWARF version 1,
and which led to the development of the base types to explicitly
describe types.

> At the moment, the DWARF spec uses generic tags like
> DW_TAG_pointer_type for every supported language's pointer type, and
> it's left to the producers and consumers how exactly to fit the
> concepts in the language specification onto the set of tags provided
> by DWARF.  At times this process has needed some clarification, but
> it's worked well enough.  To carry this approach over to expressions,
> DWARF would specify tags like DW_TAG_expr_multiply and
> DW_TAG_expr_deference, describing each clearly enough to allow the
> authors of Pascal consumers and producers to understand that the
> latter tag is the right thing to use for Pascal's '^' operator, and to
> allow a C developer to recognize it as unary '*'.

There's really no parallel here, although I can see why you might
think there is.  DW_TAG_pointer_type is primarily a source marker.  What
little semantics there may be is embodied in the base type on which it
depends.  There's no great depth of meaning in saying that the value
of a variable with this type is the address of another value.
DW_TAG_pointer_type is a description, not an operation.

Your proposed DW_TAG_expr_multiply operation would need to be defined
for every possible data type and data structure.  Or you would need
to define some scheme which would have the breadth to be able to
describe all of the possible semantics of this operation.  That's
certainly much more complex than you seem to believe.

Essentially, your suggestion is to turn DWARF into a standardized
intermediate representation, describing all of the features of the
source.  That's beyond the scope of a debugging format.

> Perhaps this is "far out in left field".  But using DWARF expressions
> for this would be a pretty serious extension of their
> responsibilities, and in the non-trivial cases would result in exactly
> the sort of ridiculous complexity (I think implementing floating-point
> in DWARF expressions is ridiculous) that you'd expect from that.  We
> would, in practice if not in the letter of the spec, be restricting
> DWARF to supporting the easy cases.

As indicated above, it isn't clear that you need to implement
floating point operations in DWARF expressions.  But even if you
did, this is not by any means a task of "ridiculous complexity".
It would require perhaps a half-dozen well defined operations
which would operate on the top of the expression stack.

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



From paul.t.robinson@hp.com  Mon Jan  7 18:24:58 2008
From: paul.t.robinson@hp.com (Robinson, Paul T NonStop)
Date: Mon, 7 Jan 2008 18:24:58 +0000
Subject: [Dwarf-Discuss] PROPOSAL: Constant expressions in location lists
In-Reply-To: <orir278e58.fsf@oliva.athome.lsd.ic.unicamp.br>
References: <20080104212847.GD6849@redhat.com>
	<8f2776cb0801052329m21b54d6ftf6b5223ae71ab54b@mail.gmail.com>
	<20080106075926.E588F26F9A3@magilla.localdomain>
	<orir278e58.fsf@oliva.athome.lsd.ic.unicamp.br>
Message-ID: <4D0A48C2F8492B48BEA398987C16C6C10D76CBD9@G3W0633.americas.hpqcorp.net>

A tangential question regarding DW_AT_location...

Alexandre Oliva wrote:

> The effect would be equivalent to that of adding a deref to
> each piece of each DW_AT_location location expression that mentions a
> memory address, except that DW_AT_location locations are assumed to be
> modifiable (and thus exclusively assigned to the mentioned variable),
> whereas a dereferenced address or a register in a DW_AT_value is
> expected to be non-modifiable or shared.

I didn't think DW_AT_location locations must be "exclusively assigned."
Copy propagation could cause multiple variables to be assigned to the
same machine location simultaneously, and their DWARF descriptions
should accurately reflect that.  (Modifying one variable implicitly
modifies the other.)  Did I misunderstand something?

--paulr



From eager@eagercon.com  Mon Jan  7 19:36:51 2008
From: eager@eagercon.com (Michael Eager)
Date: Mon, 07 Jan 2008 11:36:51 -0800
Subject: [Dwarf-Discuss] PROPOSAL: Constant expressions in location lists
In-Reply-To: <4D0A48C2F8492B48BEA398987C16C6C10D76CBD9@G3W0633.americas.hpqcorp.net>
References: <20080104212847.GD6849@redhat.com>	<8f2776cb0801052329m21b54d6ftf6b5223ae71ab54b@mail.gmail.com>	<20080106075926.E588F26F9A3@magilla.localdomain>	<orir278e58.fsf@oliva.athome.lsd.ic.unicamp.br>
	<4D0A48C2F8492B48BEA398987C16C6C10D76CBD9@G3W0633.americas.hpqcorp.net>
Message-ID: <47827F53.6000101@eagercon.com>

Robinson, Paul T (NonStop) wrote:
> A tangential question regarding DW_AT_location...
> 
> Alexandre Oliva wrote:
> 
>> The effect would be equivalent to that of adding a deref to
>> each piece of each DW_AT_location location expression that mentions a
>> memory address, except that DW_AT_location locations are assumed to be
>> modifiable (and thus exclusively assigned to the mentioned variable),
>> whereas a dereferenced address or a register in a DW_AT_value is
>> expected to be non-modifiable or shared.
> 
> I didn't think DW_AT_location locations must be "exclusively assigned."
> Copy propagation could cause multiple variables to be assigned to the
> same machine location simultaneously, and their DWARF descriptions
> should accurately reflect that.  (Modifying one variable implicitly
> modifies the other.)  Did I misunderstand something?

I think you understand correctly.  There is one location list for
each (extant) variable.  In that respect, you might call it
"exclusively assigned".  But the location that it references does
not need to be unique.

If you had code like

	a = b = 999;
	printf ("a = %d\n", a);
	printf ("b = %d\n", b);

and you had your debugger stop between the assignment and the first
printf and change the value of b, you might find that the value of
a is also changed if the compiler performed copy propogation and
replaced a with b.

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



From jimb@red-bean.com  Mon Jan  7 23:29:04 2008
From: jimb@red-bean.com (Jim Blandy)
Date: Mon, 7 Jan 2008 15:29:04 -0800
Subject: [Dwarf-Discuss] PROPOSAL: Constant expressions in location lists
In-Reply-To: <47819EA1.6010704@eagercon.com>
References: <20080104212847.GD6849@redhat.com>
	<8f2776cb0801052329m21b54d6ftf6b5223ae71ab54b@mail.gmail.com>
	<20080106075926.E588F26F9A3@magilla.localdomain>
	<8f2776cb0801060117t415f623do3dc2a75d6c78868@mail.gmail.com>
	<478114D7.7000009@eagercon.com>
	<8f2776cb0801061726w41ee8be5p3456f041a9ba157b@mail.gmail.com>
	<47819EA1.6010704@eagercon.com>
Message-ID: <8f2776cb0801071529t2b3e9b3emf2fcaaac4123b527@mail.gmail.com>

On Jan 6, 2008 7:38 PM, Michael Eager <eager at eagercon.com> wrote:
> > There's no necessary restriction on what types of values a compiler
> > might be able to optimize out; in the most general case, the values to
> > be computed could be structures, large floating-point types, etc.  So
> > DWARF needs to be able to describe how to compute values with
> > arbitrary source types.
>
> No, you only need to be able to interpret the instructions given
> by the compiler to compute a machine value.  This does not require
> that a debugger have a source language interpreter, and in particular,
> it doesn't require DWARF to be able to describe arbitrary source
> types.

I'm not sure I follow.  If the task is to be able to recompute values
of variables that have been optimized out, and those variables could
potentially have any type, then DWARF needs to be able to express how
to compute the run-time, target representations of values of arbitrary
type.

> > DWARF does have DWARF expressions, but their semantics were
> > deliberately restricted to computing address-sized values, to keep the
> > specification simple and focussed.  We're now considering using DWARF
> > expressions to compute (potentially) every type of value expressible
> > in the source language.
>
> This seems to exaggerate the problem.  You don't need to compute
> "every value expressible in the source".  Instead you need to compute
> every value expressible in the machine.  Machines have a very narrow
> range of types, usually two: binary integer and floating point.  And
> it may not be necessary to even compute that range -- all you care
> about is bit patterns.

Yes --- but this isn't a simplification.  If the variable that has
been optimized out has a class type (which I'll bet C++ compilers
dealing with STL code do now), then the compiler would need to produce
DWARF expressions that yield the run-time, target representation
values having that class type.

> > Following this approach, If the compiler had optimized out a
> > floating-point value, but knew how to recompute it if desired, and
> > wished to express this in DWARF, the compiler would need to produce a
> > DWARF expression that would yield the appropriate floating-point
> > value, in target format.
>
> That's true, but it doesn't necessarily follow that DWARF expressions
> need to perform floating point computations.
>
> Let's say you had the following snippet of code:
>
>      float pi(void) {
>         float val = 3.14159;
>         return val;
>      }
>
> A reasonable compiler would discard 'val' resulting in the debugger
> giving a message saying that the value was not available.  To
> reconstruct the value of this discarded variable, all you need to
> do is generate the bit pattern which has this value: 0x400921fa.

This case is already covered by DW_AT_const_value.  Presenting
constant bit patterns is no trouble, I agree.  I was told up-thread
that the case where values do actually need to be computed is what
we're concerned with here.

> Essentially, your suggestion is to turn DWARF into a standardized
> intermediate representation, describing all of the features of the
> source.  That's beyond the scope of a debugging format.

That wasn't my proposal at all.  It was much less ambitious than that.
I don't think I explained myself well.  Having made a second try, I'll
drop the suggestion.


> As indicated above, it isn't clear that you need to implement
> floating point operations in DWARF expressions.  But even if you
> did, this is not by any means a task of "ridiculous complexity".
> It would require perhaps a half-dozen well defined operations
> which would operate on the top of the expression stack.

If we extend the DWARF expression stack to hold floating-point values,
of various widths, then that would address the problem.  I think it
would be more than a half-dozen operations, but still quite practical.
I think we'll end up wanting to expand our set of arithmetic operators
as well.



From eager@eagercon.com  Tue Jan  8 00:03:17 2008
From: eager@eagercon.com (Michael Eager)
Date: Mon, 07 Jan 2008 16:03:17 -0800
Subject: [Dwarf-Discuss] PROPOSAL: Constant expressions in location lists
In-Reply-To: <8f2776cb0801071529t2b3e9b3emf2fcaaac4123b527@mail.gmail.com>
References: <20080104212847.GD6849@redhat.com>	
	<8f2776cb0801052329m21b54d6ftf6b5223ae71ab54b@mail.gmail.com>	
	<20080106075926.E588F26F9A3@magilla.localdomain>	
	<8f2776cb0801060117t415f623do3dc2a75d6c78868@mail.gmail.com>	
	<478114D7.7000009@eagercon.com>	
	<8f2776cb0801061726w41ee8be5p3456f041a9ba157b@mail.gmail.com>	
	<47819EA1.6010704@eagercon.com>
	<8f2776cb0801071529t2b3e9b3emf2fcaaac4123b527@mail.gmail.com>
Message-ID: <4782BDC5.7060607@eagercon.com>

Jim Blandy wrote:
> On Jan 6, 2008 7:38 PM, Michael Eager <eager at eagercon.com> wrote:
>>> There's no necessary restriction on what types of values a compiler
>>> might be able to optimize out; in the most general case, the values to
>>> be computed could be structures, large floating-point types, etc.  So
>>> DWARF needs to be able to describe how to compute values with
>>> arbitrary source types.
>> No, you only need to be able to interpret the instructions given
>> by the compiler to compute a machine value.  This does not require
>> that a debugger have a source language interpreter, and in particular,
>> it doesn't require DWARF to be able to describe arbitrary source
>> types.
> 
> I'm not sure I follow.  If the task is to be able to recompute values
> of variables that have been optimized out, and those variables could
> potentially have any type, then DWARF needs to be able to express how
> to compute the run-time, target representations of values of arbitrary
> type.

Yes, only target representations.  That's values that the hardware supports:
int and float.  These are the base types defined for the machine.

>>> DWARF does have DWARF expressions, but their semantics were
>>> deliberately restricted to computing address-sized values, to keep the
>>> specification simple and focussed.  We're now considering using DWARF
>>> expressions to compute (potentially) every type of value expressible
>>> in the source language.
>> This seems to exaggerate the problem.  You don't need to compute
>> "every value expressible in the source".  Instead you need to compute
>> every value expressible in the machine.  Machines have a very narrow
>> range of types, usually two: binary integer and floating point.  And
>> it may not be necessary to even compute that range -- all you care
>> about is bit patterns.
> 
> Yes --- but this isn't a simplification.  If the variable that has
> been optimized out has a class type (which I'll bet C++ compilers
> dealing with STL code do now), then the compiler would need to produce
> DWARF expressions that yield the run-time, target representation
> values having that class type.

But only values which are base types.  Every source language
type is composed of base types, either directly or indirectly.

>> As indicated above, it isn't clear that you need to implement
>> floating point operations in DWARF expressions.  But even if you
>> did, this is not by any means a task of "ridiculous complexity".
>> It would require perhaps a half-dozen well defined operations
>> which would operate on the top of the expression stack.
> 
> If we extend the DWARF expression stack to hold floating-point values,
> of various widths, then that would address the problem.  I think it
> would be more than a half-dozen operations, but still quite practical.
> I think we'll end up wanting to expand our set of arithmetic operators
> as well.

Agreed.

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



From Chris.Quenelle@Sun.COM  Tue Jan  8 00:11:07 2008
From: Chris.Quenelle@Sun.COM (Chris Quenelle)
Date: Mon, 07 Jan 2008 16:11:07 -0800
Subject: [Dwarf-Discuss] PROPOSAL: Constant expressions in location lists
In-Reply-To: <8f2776cb0801071529t2b3e9b3emf2fcaaac4123b527@mail.gmail.com>
References: <20080104212847.GD6849@redhat.com>
	<8f2776cb0801052329m21b54d6ftf6b5223ae71ab54b@mail.gmail.com>
	<20080106075926.E588F26F9A3@magilla.localdomain>
	<8f2776cb0801060117t415f623do3dc2a75d6c78868@mail.gmail.com>
	<478114D7.7000009@eagercon.com>
	<8f2776cb0801061726w41ee8be5p3456f041a9ba157b@mail.gmail.com>
	<47819EA1.6010704@eagercon.com>
	<8f2776cb0801071529t2b3e9b3emf2fcaaac4123b527@mail.gmail.com>
Message-ID: <4782BF9B.8080600@sun.com>

Jim Blandy wrote:
> If the task is to be able to recompute values
> of variables that have been optimized out, and those variables could
> potentially have any type, then DWARF needs to be able to express how
> to compute the run-time, target representations of values of arbitrary
> type.

This requires the compiler backend to retain the knowledge
of variable-related optimizations in a structured way,
and to record those transformation in the reverse way they
were performed to the code.  This sort of ability isn't
likely to appear full-blown in any compiler without some
serious evolution along the way.  The Sun compilers are expected
to learn how to record the simpler transformations first, and 
eventually move on to more complex optimizations.

The existing approach calls for making the leap from completely 
source level (in the symbolic dies) to the completely binary 
level (in the dwarf expressions).  This gap might be leapable
for simple to moderate optimizations and types.  But for more 
complex transformations the dwarf expressions needed to 
"jump the gap" might become very complex indeed.  Perhaps
impossibly complex (or perhaps not), but perhaps just prohibitively
complex.

Say you have some large and complex C++ class and a single variable
of that type.  Now let's say the optimizer has placed one tiny field
of a deeply nested inner member of that class into a register.
The only die is for the top-level variable.  How should the compiler
record that one tiny part of the overall class is now in a register?

The pragmatic answer is that we don't really have to answer that question
until someone says they want to do it.  Of course, it would be nice
to know where dwarf is headed, in a general way.


--chris



From eager@eagercon.com  Tue Jan  8 00:31:02 2008
From: eager@eagercon.com (Michael Eager)
Date: Mon, 07 Jan 2008 16:31:02 -0800
Subject: [Dwarf-Discuss] PROPOSAL: Constant expressions in location lists
In-Reply-To: <4782BF9B.8080600@sun.com>
References: <20080104212847.GD6849@redhat.com>	<8f2776cb0801052329m21b54d6ftf6b5223ae71ab54b@mail.gmail.com>	<20080106075926.E588F26F9A3@magilla.localdomain>	<8f2776cb0801060117t415f623do3dc2a75d6c78868@mail.gmail.com>	<478114D7.7000009@eagercon.com>	<8f2776cb0801061726w41ee8be5p3456f041a9ba157b@mail.gmail.com>	<47819EA1.6010704@eagercon.com>	<8f2776cb0801071529t2b3e9b3emf2fcaaac4123b527@mail.gmail.com>
	<4782BF9B.8080600@sun.com>
Message-ID: <4782C446.1020300@eagercon.com>

Chris Quenelle wrote:

> Say you have some large and complex C++ class and a single variable
> of that type.  Now let's say the optimizer has placed one tiny field
> of a deeply nested inner member of that class into a register.
> The only die is for the top-level variable.  How should the compiler
> record that one tiny part of the overall class is now in a register?

Unless I've misunderstood you, DWARF can describe this currently.
The location list for the member points to the register and gives
the scope where this is valid.

I'm not sure what you mean by having only the DIE for the "top-level
variable".  If you mean that the DWARF only contains a DW_TAG_class_type
without any of the specification for the members, then this would not
be well formed.

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



From Chris.Quenelle@Sun.COM  Tue Jan  8 02:24:40 2008
From: Chris.Quenelle@Sun.COM (Chris Quenelle)
Date: Mon, 07 Jan 2008 18:24:40 -0800
Subject: [Dwarf-Discuss] PROPOSAL: Constant expressions in location lists
In-Reply-To: <4782C446.1020300@eagercon.com>
References: <20080104212847.GD6849@redhat.com>
	<8f2776cb0801052329m21b54d6ftf6b5223ae71ab54b@mail.gmail.com>
	<20080106075926.E588F26F9A3@magilla.localdomain>
	<8f2776cb0801060117t415f623do3dc2a75d6c78868@mail.gmail.com>
	<478114D7.7000009@eagercon.com>
	<8f2776cb0801061726w41ee8be5p3456f041a9ba157b@mail.gmail.com>
	<47819EA1.6010704@eagercon.com>
	<8f2776cb0801071529t2b3e9b3emf2fcaaac4123b527@mail.gmail.com>
	<4782BF9B.8080600@sun.com> <4782C446.1020300@eagercon.com>
Message-ID: <4782DEE8.50508@sun.com>

There will normally be a huge amount of information about the type, 
but the variable itself will be represented by a single die
which references the type.  Location information on class types 
should be for the purpose of telling you how to go from the 'this'
pointer to the member data.  It wouldn't be correct to add 
location information related to specific code locations, since
different variables of the same type might have different 
location information for this kind of thing.

--chris


Michael Eager wrote:
> Chris Quenelle wrote:
> 
>> Say you have some large and complex C++ class and a single variable
>> of that type.  Now let's say the optimizer has placed one tiny field
>> of a deeply nested inner member of that class into a register.
>> The only die is for the top-level variable.  How should the compiler
>> record that one tiny part of the overall class is now in a register?
> 
> Unless I've misunderstood you, DWARF can describe this currently.
> The location list for the member points to the register and gives
> the scope where this is valid.
> 
> I'm not sure what you mean by having only the DIE for the "top-level
> variable".  If you mean that the DWARF only contains a DW_TAG_class_type
> without any of the specification for the members, then this would not
> be well formed.
> 




From jimb@red-bean.com  Tue Jan  8 07:20:09 2008
From: jimb@red-bean.com (Jim Blandy)
Date: Mon, 7 Jan 2008 23:20:09 -0800
Subject: [Dwarf-Discuss] Default values
Message-ID: <8f2776cb0801072320n4a92cbf2q45ecfc7189f0066f@mail.gmail.com>

I have a question about a part of the spec that seems unclear to me.
Section 4.1, numbered para 9 describes DW_AT_default_value, which can
refer to a "subroutine" to compute the default value to pass.  In this
case, does the term "subroutine" refer to a function in the user's
program that the debugger can invoke?  What arguments should the
debugger pass?  Is the subroutine required to accept no arguments?
Does this mean that in order to describe the C++ declarations:

     extern float d;
     extern float foo (float x = d * 2);

the producer would need to emit machine code into the user's program,
generate a die describing that code, and have x's DW_AT_default_value
attribute refer to that die?

Or, did this mean to say "DWARF procedure", as described in section
5.16, instead of "subroutine"?  If that's the case, then we have a
situation in the existing spec where DWARF expressions compute values
of potentially arbitrary type.

But I have doubts about either reading.



From eager@eagercon.com  Tue Jan  8 08:28:38 2008
From: eager@eagercon.com (Michael Eager)
Date: Tue, 08 Jan 2008 00:28:38 -0800
Subject: [Dwarf-Discuss] Default values
In-Reply-To: <8f2776cb0801072320n4a92cbf2q45ecfc7189f0066f@mail.gmail.com>
References: <8f2776cb0801072320n4a92cbf2q45ecfc7189f0066f@mail.gmail.com>
Message-ID: <47833436.9000407@eagercon.com>

Jim Blandy wrote:
> I have a question about a part of the spec that seems unclear to me.
> Section 4.1, numbered para 9 describes DW_AT_default_value, which can
> refer to a "subroutine" to compute the default value to pass.  In this
> case, does the term "subroutine" refer to a function in the user's
> program that the debugger can invoke?  What arguments should the
> debugger pass?  Is the subroutine required to accept no arguments?
> Does this mean that in order to describe the C++ declarations:
> 
>      extern float d;
>      extern float foo (float x = d * 2);
> 
> the producer would need to emit machine code into the user's program,
> generate a die describing that code, and have x's DW_AT_default_value
> attribute refer to that die?
> 
> Or, did this mean to say "DWARF procedure", as described in section
> 5.16, instead of "subroutine"?  If that's the case, then we have a
> situation in the existing spec where DWARF expressions compute values
> of potentially arbitrary type.

A DW_AT_default_value attribute points to a DIE which describes the
default value.  This is either a constant or a reference to a variable
or a subroutine.  DWARF cannot describe an expression as a default
value.  In this case, a compiler could emit a hidden subroutine which
computed the default value. The DW_AT_default_value attribute would
refer to the DIE for this hidden subroutine.

This is one of the areas where the specification allows much to the
readers imagination, without a lot of guidance.  I would imagine that
the subroutine is called using the same calling convention as a
normal function.  No arguments are passed to the subroutine and the
value, returned according to the ABI, would be of the appropriate type
for the formal parameter.  That's my understanding, but it certainly could
be made much clearer with some additional commentary.


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



From roland@redhat.com  Tue Jan  8 08:40:26 2008
From: roland@redhat.com (Roland McGrath)
Date: Tue,  8 Jan 2008 00:40:26 -0800 (PST)
Subject: [Dwarf-Discuss] Default values
In-Reply-To: Michael Eager's message of  Tuesday, 
	8 January 2008 00:28:38 -0800 <47833436.9000407@eagercon.com> 
References: <8f2776cb0801072320n4a92cbf2q45ecfc7189f0066f@mail.gmail.com> 
	<47833436.9000407@eagercon.com> 
Message-ID: <20080108084026.C684C26F9A5@magilla.localdomain>

I read it the same way you do, but with the same reservation about the          
extreme vagueness of the mentions of subroutines.  (In some other cases         
intended to be as loosely specified, there is more explicit wording saying      
that DWARF isn't trying to tie all of this down.)                               
                                                                                
Does anybody on the list represent an extant producer that actually emits       
DW_AT_default_value with a DIE reference?                                       
                                                                                
                                                                                
Thanks,                                                                         
Roland                                                                          
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
        



From kushneeraj@gmail.com  Mon Jan 21 05:23:03 2008
From: kushneeraj@gmail.com (Neeraj kushwaha)
Date: Mon, 21 Jan 2008 10:53:03 +0530
Subject: [Dwarf-Discuss] find local variable information from the dwarf
Message-ID: <df5e18bd0801202123v74d68544n26dcd9f98ab27606@mail.gmail.com>

Hi All,

I am trying to find the location and value of local variable in a stack
frame from the core dump.
As GDB can fetch the value and location of local variable using the
information from the dwarf debugging format.

I am trying to manually find the location and value of the local variable
from the core.

This is what i did; from the a.out, I extracted the dwarf information using
"dwarfdump -a a.out"

and using the GDB i am trying to print the dump from the core "x/88b main1"

But I am not able to find the location information of the local variable

for example:

        DW_AT_name                  c
        DW_AT_decl_file             1 /home/neeraj/4.c
        DW_AT_decl_line             15
        DW_AT_type                  <177>
        DW_AT_location              DW_OP_fbreg -20


local variable is at location DW_OP_fbreg - 20. But how to find the
DW_OP_fbreg?

Secondly I don't see the local variable are word aligned.

Please anyone guide me how to find the location and value of local variable
from the dwarf format and looking at the dump.

I am putting all the information here. (source code, gdb dump, dwarf
information)

/* 4.c */
#include<stdio.h>

int main1()
{
int b=0xabccddef;
int *p=0;
*p=10;
return 0;
}

int main()
{
int c=0xeeffeeff;
int ab=0xaabbccdd;
main1();
return 0;
}

-----------------------------------------------------------------------

(gdb) x/88b main1
0x8048374 <main1>:      0x55    0x89    0xe5    0x83    0xec    0x10
0xc7    0x45
0x804837c <main1+8>:    0xf8    0xef    0xdd    0xcc    0xab    0xc7
0x45    0xfc
0x8048384 <main1+16>:   0x00    0x00    0x00    0x00    0x8b    0x45
0xfc    0xc7
0x804838c <main1+24>:   0x00    0x0a    0x00    0x00    0x00    0xb8
0x00    0x00
0x8048394 <main1+32>:   0x00    0x00    0xc9    0xc3    0x8d    0x4c
0x24    0x04
0x804839c <main+4>:     0x83    0xe4    0xf0    0xff    0x71    0xfc
0x55    0x89
0x80483a4 <main+12>:    0xe5    0x51    0x83    0xec    0x10    0xc7
0x45    0xf4
0x80483ac <main+20>:    0xff    0xee    0xff    0xee    0xc7    0x45
0xf8    0xdd
0x80483b4 <main+28>:    0xcc    0xbb    0xaa    0xe8    0xb8    0xff
0xff    0xff
0x80483bc <main+36>:    0xb8    0x00    0x00    0x00    0x00    0x83
0xc4    0x10
0x80483c4 <main+44>:    0x59    0x5d    0x8d    0x61    0xfc    0xc3
0x90    0x90

-------------------------------------------------------------------------------------------


.debug_info

COMPILE_UNIT<header overall offset = 0>:
<0><   11>    DW_TAG_compile_unit
        DW_AT_stmt_list             0
        DW_AT_high_pc               0x80483ca
        DW_AT_low_pc                0x8048374
        DW_AT_producer              GNU C 4.1.2 20070925 (Red Hat 4.1.2-27)
        DW_AT_language              DW_LANG_C89
        DW_AT_name                  4.c
        DW_AT_comp_dir              /home/neeraj

LOCAL_SYMBOLS:
<1><   82>    DW_TAG_base_type
        DW_AT_name                  unsigned int
        DW_AT_byte_size             4
        DW_AT_encoding              DW_ATE_unsigned
<1><   89>    DW_TAG_base_type
        DW_AT_name                  unsigned char
        DW_AT_byte_size             1
        DW_AT_encoding              DW_ATE_unsigned_char
<1><  106>    DW_TAG_base_type
        DW_AT_name                  short unsigned int
        DW_AT_byte_size             2
        DW_AT_encoding              DW_ATE_unsigned
<1><  128>    DW_TAG_base_type
        DW_AT_name                  long unsigned int
        DW_AT_byte_size             4
        DW_AT_encoding              DW_ATE_unsigned
<1><  149>    DW_TAG_base_type
        DW_AT_name                  signed char
        DW_AT_byte_size             1
        DW_AT_encoding              DW_ATE_signed_char
<1><  164>    DW_TAG_base_type
        DW_AT_name                  short int
        DW_AT_byte_size             2
        DW_AT_encoding              DW_ATE_signed
<1><  177>    DW_TAG_base_type
        DW_AT_name                  int
        DW_AT_byte_size             4
        DW_AT_encoding              DW_ATE_signed
<1><  184>    DW_TAG_base_type
        DW_AT_name                  long long int
        DW_AT_byte_size             8
        DW_AT_encoding              DW_ATE_signed
<1><  201>    DW_TAG_base_type
        DW_AT_name                  long long unsigned int
        DW_AT_byte_size             8
        DW_AT_encoding              DW_ATE_unsigned
<1><  227>    DW_TAG_base_type
        DW_AT_name                  long int
        DW_AT_byte_size             4
        DW_AT_encoding              DW_ATE_signed
<1><  239>    DW_TAG_base_type
        DW_AT_name                  unsigned int
        DW_AT_byte_size             4
        DW_AT_encoding              DW_ATE_unsigned
<1><  246>    DW_TAG_base_type
        DW_AT_name                  char
        DW_AT_byte_size             1
        DW_AT_encoding              DW_ATE_signed_char
<1><  254>    DW_TAG_subprogram
        DW_AT_sibling               <309>
        DW_AT_external              yes(1)
        DW_AT_name                  main1
        DW_AT_decl_file             1 /home/neeraj/4.c
        DW_AT_decl_line             6
        DW_AT_type                  <177>
        DW_AT_low_pc                0x8048374
        DW_AT_high_pc               0x8048398
        DW_AT_frame_base            [ 0]<lowpc=0x0><highpc=0x1>DW_OP_breg4+4
                    [ 1]<lowpc=0x1><highpc=0x3>DW_OP_breg4+8
                    [ 2]<lowpc=0x3><highpc=0x24>DW_OP_breg5+8
<2><  284>    DW_TAG_variable
        DW_AT_name                  b
        DW_AT_decl_file             1 /home/neeraj/4.c
        DW_AT_decl_line             7
        DW_AT_type                  <177>
        DW_AT_location              DW_OP_fbreg -16
<2><  296>    DW_TAG_variable
        DW_AT_name                  p
        DW_AT_decl_file             1 /home/neeraj/4.c
        DW_AT_decl_line             8
        DW_AT_type                  <309>
        DW_AT_location              DW_OP_fbreg -12
<1><  309>    DW_TAG_pointer_type
        DW_AT_byte_size             4
        DW_AT_type                  <177>
<1><  315>    DW_TAG_subprogram
        DW_AT_external              yes(1)
        DW_AT_name                  main
        DW_AT_decl_file             1 /home/neeraj/4.c
        DW_AT_decl_line             14
        DW_AT_type                  <177>
        DW_AT_low_pc                0x8048398
        DW_AT_high_pc               0x80483ca
        DW_AT_frame_base            [
0]<lowpc=0x24><highpc=0x28>DW_OP_breg4+4
                    [ 1]<lowpc=0x28><highpc=0x2e>DW_OP_reg1
                    [ 2]<lowpc=0x2e><highpc=0x2f>DW_OP_breg4+4
                    [ 3]<lowpc=0x2f><highpc=0x31>DW_OP_breg4+8
                    [ 4]<lowpc=0x31><highpc=0x56>DW_OP_breg5+8
<2><  340>    DW_TAG_variable
        DW_AT_name                  c
        DW_AT_decl_file             1 /home/neeraj/4.c
        DW_AT_decl_line             15
        DW_AT_type                  <177>
        DW_AT_location              DW_OP_fbreg -20
<2><  352>    DW_TAG_variable
        DW_AT_name                  ab
        DW_AT_decl_file             1 /home/neeraj/4.c
        DW_AT_decl_line             16
        DW_AT_type                  <177>
        DW_AT_location              DW_OP_fbreg -16

line number info
<source>    [row,column]    <pc>    //<new statement or basic block
/home/neeraj/4.c:    [  6,-1]    0x8048374    // new statement
/home/neeraj/4.c:    [  7,-1]    0x804837a    // new statement
/home/neeraj/4.c:    [  8,-1]    0x8048381    // new statement
/home/neeraj/4.c:    [  9,-1]    0x8048388    // new statement
/home/neeraj/4.c:    [ 10,-1]    0x8048391    // new statement
/home/neeraj/4.c:    [ 11,-1]    0x8048396    // new statement
/home/neeraj/4.c:    [ 14,-1]    0x8048398    // new statement
/home/neeraj/4.c:    [ 15,-1]    0x8048398    // new statement
/home/neeraj/4.c:    [ 16,-1]    0x804839f    // new statement
/home/neeraj/4.c:    [ 17,-1]    0x80483a6    // new statement
/home/neeraj/4.c:    [ 18,-1]    0x80483ab    // new statement
/home/neeraj/4.c:    [ 19,-1]    0x80483b0    // new statement
/home/neeraj/4.c:    [ 19,-1]    0x80483b0    // new statement    // end of
text sequence

.debug_pubnames
global main1           die 254, cu-die 11, off-in-cu 254, cu 0
global main            die 315, cu-die 11, off-in-cu 315, cu 0

.debug_macinfo

.debug_loc format <o b e l> means section-offset begin-addr end-addr
length-of-block-entry
     <obel> 0x00000000 0x000000000 0x00000001        2
     <obel> 0x0000000c 0x000000001 0x00000003        2
     <obel> 0x00000018 0x000000003 0x00000024        2
     <obel> 0x00000024 0x000000000 0x00000000        0
     <obel> 0x0000002c 0x000000024 0x00000028        2
     <obel> 0x00000038 0x000000028 0x0000002e        1
     <obel> 0x00000043 0x00000002e 0x0000002f        2
     <obel> 0x0000004f 0x00000002f 0x00000031        2
     <obel> 0x0000005b 0x000000031 0x00000056        2
     <obel> 0x00000067 0x000000000 0x00000000        0

.debug_abbrev
<   1><    0><code:  1> DW_TAG_compile_unit DW_children_yes
      <    3>    DW_AT_stmt_list             DW_FORM_data4
      <    5>    DW_AT_high_pc               DW_FORM_addr
      <    7>    DW_AT_low_pc                DW_FORM_addr
      <    9>    DW_AT_producer              DW_FORM_string
      <   11>    DW_AT_language              DW_FORM_data1
      <   13>    DW_AT_name                  DW_FORM_string
      <   15>    DW_AT_comp_dir              DW_FORM_string
<   2><   19><code:  2> DW_TAG_base_type    DW_children_no
      <   22>    DW_AT_name                  DW_FORM_strp
      <   24>    DW_AT_byte_size             DW_FORM_data1
      <   26>    DW_AT_encoding              DW_FORM_data1
<   3><   30><code:  3> DW_TAG_base_type    DW_children_no
      <   33>    DW_AT_name                  DW_FORM_string
      <   35>    DW_AT_byte_size             DW_FORM_data1
      <   37>    DW_AT_encoding              DW_FORM_data1
<   4><   41><code:  4> DW_TAG_subprogram   DW_children_yes
      <   44>    DW_AT_sibling               DW_FORM_ref4
      <   46>    DW_AT_external              DW_FORM_flag
      <   48>    DW_AT_name                  DW_FORM_string
      <   50>    DW_AT_decl_file             DW_FORM_data1
      <   52>    DW_AT_decl_line             DW_FORM_data1
      <   54>    DW_AT_type                  DW_FORM_ref4
      <   56>    DW_AT_low_pc                DW_FORM_addr
      <   58>    DW_AT_high_pc               DW_FORM_addr
      <   60>    DW_AT_frame_base            DW_FORM_data4
<   5><   64><code:  5> DW_TAG_variable     DW_children_no
      <   67>    DW_AT_name                  DW_FORM_string
      <   69>    DW_AT_decl_file             DW_FORM_data1
      <   71>    DW_AT_decl_line             DW_FORM_data1
      <   73>    DW_AT_type                  DW_FORM_ref4
      <   75>    DW_AT_location              DW_FORM_block1
<   6><   79><code:  6> DW_TAG_pointer_type DW_children_no
      <   82>    DW_AT_byte_size             DW_FORM_data1
      <   84>    DW_AT_type                  DW_FORM_ref4
<   7><   88><code:  7> DW_TAG_subprogram   DW_children_yes
      <   91>    DW_AT_external              DW_FORM_flag
      <   93>    DW_AT_name                  DW_FORM_string
      <   95>    DW_AT_decl_file             DW_FORM_data1
      <   97>    DW_AT_decl_line             DW_FORM_data1
      <   99>    DW_AT_type                  DW_FORM_ref4
      <  101>    DW_AT_low_pc                DW_FORM_addr
      <  103>    DW_AT_high_pc               DW_FORM_addr
      <  105>    DW_AT_frame_base            DW_FORM_data4
<   8><  109><code:  0> null .debug_abbrev entry

.debug_string
name at offset 0, length 12 is unsigned int

.debug_aranges

arange starts at 8048374, length of 86, cu_die_offset = 11

COMPILE_UNIT<header overall offset = 0>:
<0><   11>    DW_TAG_compile_unit
        DW_AT_stmt_list             0
        DW_AT_high_pc               0x80483ca
        DW_AT_low_pc                0x8048374
        DW_AT_producer              GNU C 4.1.2 20070925 (Red Hat 4.1.2-27)
        DW_AT_language              DW_LANG_C89
        DW_AT_name                  4.c
        DW_AT_comp_dir              /home/neeraj

.debug_frame

fde:
<  0><0x8048374:0x8048398><main1><fde offset 0x14 length: 0x14><eh offset
none>
    08048374:    cfa=04(r4/a0) r8/t0=-4(cfa)
    08048375:    cfa=08(r4/a0) r5/a1=-8(cfa) r8/t0=-4(cfa)
    08048377:    cfa=08(r5/a1) r5/a1=-8(cfa) r8/t0=-4(cfa)
<  0><0x8048398:0x80483ca><main><fde offset 0x2c length: 0x24><eh offset
none>
    08048398:    cfa=04(r4/a0) r8/t0=-4(cfa)
    0804839c:    cfa=00(r1/at) r4/a0=r1/at r8/t0=-4(cfa)
    080483a2:    cfa=04(r4/a0) r4/a0=r1/at r8/t0=-4(cfa)
    080483a3:    cfa=08(r4/a0) r4/a0=r1/at r5/a1=-8(cfa) r8/t0=-4(cfa)
    080483a5:    cfa=08(r5/a1) r4/a0=r1/at r5/a1=-8(cfa) r8/t0=-4(cfa)
    080483a6:    cfa=08(r5/a1) r4/a0=-12(cfa) r5/a1=-8(cfa) r8/t0=-4(cfa)

.eh_frame

fde:
<  0><0xfffffee8:0xffffff51><><fde offset 0x8c length: 0x1c><eh offset none>
    fffffee8:    cfa=04(r4/a0) r8/t0=-4(cfa)
    fffffee9:    cfa=08(r4/a0) r5/a1=-8(cfa) r8/t0=-4(cfa)
    fffffeeb:    cfa=08(r5/a1) r5/a1=-8(cfa) r8/t0=-4(cfa)
    fffffeee:    cfa=08(r5/a1) r3/v1=-20(cfa) r5/a1=-8(cfa) r6/a2=-16(cfa)
r7/a3=-12(cfa) r8/t0=-4(cfa)
<  0><0xfffffef4:0xfffffef9><><fde offset 0x70 length: 0x18><eh offset none>
    fffffef4:    cfa=04(r4/a0) r8/t0=-4(cfa)
    fffffef5:    cfa=08(r4/a0) r5/a1=-8(cfa) r8/t0=-4(cfa)
    fffffef7:    cfa=08(r5/a1) r5/a1=-8(cfa) r8/t0=-4(cfa)

.debug_static_func

.debug_static_vars

.debug_types

.debug_weaknames


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


From davea42@earthlink.net  Mon Jan 21 19:20:56 2008
From: davea42@earthlink.net (David Anderson)
Date: Mon, 21 Jan 2008 11:20:56 -0800
Subject: [Dwarf-Discuss] find local variable information from the dwarf
In-Reply-To: <df5e18bd0801202123v74d68544n26dcd9f98ab27606@mail.gmail.com>
References: <df5e18bd0801202123v74d68544n26dcd9f98ab27606@mail.gmail.com>
Message-ID: <4794F098.5010003@earthlink.net>

Neeraj kushwaha wrote:
> Hi All,
>
> I am trying to find the location and value of local variable in a stack
> frame from the core dump.
> As GDB can fetch the value and location of local variable using the
> information from the dwarf debugging format.
>
> I am trying to manually find the location and value of the local variable
> from the core.
>
> This is what i did; from the a.out, I extracted the dwarf information using
> "dwarfdump -a a.out"
>
> and using the GDB i am trying to print the dump from the core "x/88b main1"
>
> But I am not able to find the location information of the local variable
>
> for example:
>
>         DW_AT_name                  c
>         DW_AT_decl_file             1 /home/neeraj/4.c
>         DW_AT_decl_line             15
>         DW_AT_type                  <177>
>         DW_AT_location              DW_OP_fbreg -20
>
>
> local variable is at location DW_OP_fbreg - 20. But how to find the
> DW_OP_fbreg?
>
>   

Look back a few lines.  The fbreg is defined in the subprogram
DIE (DW_AT_frame_base):

> <1><  315>    DW_TAG_subprogram
>         DW_AT_external              yes(1)
>         DW_AT_name                  main
>         DW_AT_decl_file             1 /home/neeraj/4.c
>         DW_AT_decl_line             14
>         DW_AT_type                  <177>
>         DW_AT_low_pc                0x8048398
>         DW_AT_high_pc               0x80483ca
>         DW_AT_frame_base            [
> 0]<lowpc=0x24><highpc=0x28>DW_OP_breg4+4
>                     [ 1]<lowpc=0x28><highpc=0x2e>DW_OP_reg1
>                     [ 2]<lowpc=0x2e><highpc=0x2f>DW_OP_breg4+4
>                     [ 3]<lowpc=0x2f><highpc=0x31>DW_OP_breg4+8
>                     [ 4]<lowpc=0x31><highpc=0x56>DW_OP_breg5+8
>   

Hope that helps.
David Anderson.



From kushneeraj@gmail.com  Tue Jan 22 01:38:39 2008
From: kushneeraj@gmail.com (Neeraj kushwaha)
Date: Tue, 22 Jan 2008 07:08:39 +0530
Subject: [Dwarf-Discuss] find local variable information from the dwarf
In-Reply-To: <4794F098.5010003@earthlink.net>
References: <df5e18bd0801202123v74d68544n26dcd9f98ab27606@mail.gmail.com>
	<4794F098.5010003@earthlink.net>
Message-ID: <df5e18bd0801211738h182c821nc41a142ca323a898@mail.gmail.com>

Thanks for the reply.

But how to interpret these lines

>*         DW_AT_frame_base            [
*>* 0]<lowpc=0x24><highpc=0x28>DW_OP_breg4+4
*>*                     [ 1]<lowpc=0x28><highpc=0x2e>DW_OP_reg1
*>*                     [ 2]<lowpc=0x2e><highpc=0x2f>DW_OP_breg4+4
*>*                     [ 3]<lowpc=0x2f><highpc=0x31>DW_OP_breg4+8
*>*                     [ 4]<lowpc=0x31><highpc=0x56>DW_OP_breg5+8
*

Please explain briefly.



Regards

Neeraj

On Jan 22, 2008 12:50 AM, David Anderson <davea42 at earthlink.net> wrote:

> Neeraj kushwaha wrote:
> > Hi All,
> >
> > I am trying to find the location and value of local variable in a stack
> > frame from the core dump.
> > As GDB can fetch the value and location of local variable using the
> > information from the dwarf debugging format.
> >
> > I am trying to manually find the location and value of the local
> variable
> > from the core.
> >
> > This is what i did; from the a.out, I extracted the dwarf information
> using
> > "dwarfdump -a a.out"
> >
> > and using the GDB i am trying to print the dump from the core "x/88b
> main1"
> >
> > But I am not able to find the location information of the local variable
> >
> > for example:
> >
> >         DW_AT_name                  c
> >         DW_AT_decl_file             1 /home/neeraj/4.c
> >         DW_AT_decl_line             15
> >         DW_AT_type                  <177>
> >         DW_AT_location              DW_OP_fbreg -20
> >
> >
> > local variable is at location DW_OP_fbreg - 20. But how to find the
> > DW_OP_fbreg?
> >
> >
>
> Look back a few lines.  The fbreg is defined in the subprogram
> DIE (DW_AT_frame_base):
>
> > <1><  315>    DW_TAG_subprogram
> >         DW_AT_external              yes(1)
> >         DW_AT_name                  main
> >         DW_AT_decl_file             1 /home/neeraj/4.c
> >         DW_AT_decl_line             14
> >         DW_AT_type                  <177>
> >         DW_AT_low_pc                0x8048398
> >         DW_AT_high_pc               0x80483ca
> >         DW_AT_frame_base            [
> > 0]<lowpc=0x24><highpc=0x28>DW_OP_breg4+4
> >                     [ 1]<lowpc=0x28><highpc=0x2e>DW_OP_reg1
> >                     [ 2]<lowpc=0x2e><highpc=0x2f>DW_OP_breg4+4
> >                     [ 3]<lowpc=0x2f><highpc=0x31>DW_OP_breg4+8
> >                     [ 4]<lowpc=0x31><highpc=0x56>DW_OP_breg5+8
> >
>
> Hope that helps.
> David Anderson.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20080122/a30feedf/attachment.htm>


From davea42@earthlink.net  Tue Jan 22 02:56:39 2008
From: davea42@earthlink.net (David Anderson)
Date: Mon, 21 Jan 2008 18:56:39 -0800
Subject: [Dwarf-Discuss] find local variable information from the dwarf
In-Reply-To: <df5e18bd0801211738h182c821nc41a142ca323a898@mail.gmail.com>
References: <df5e18bd0801202123v74d68544n26dcd9f98ab27606@mail.gmail.com>	
	<4794F098.5010003@earthlink.net>
	<df5e18bd0801211738h182c821nc41a142ca323a898@mail.gmail.com>
Message-ID: <47955B67.8080703@earthlink.net>

Neeraj kushwaha wrote:
> Thanks for the reply.
>
> But how to interpret these lines
>
>   
>> *         DW_AT_frame_base            [
>>     
> *>* 0]<lowpc=0x24><highpc=0x28>DW_OP_breg4+4
> *>*                     [ 1]<lowpc=0x28><highpc=0x2e>DW_OP_reg1
> *>*                     [ 2]<lowpc=0x2e><highpc=0x2f>DW_OP_breg4+4
> *>*                     [ 3]<lowpc=0x2f><highpc=0x31>DW_OP_breg4+8
> *>*                     [ 4]<lowpc=0x31><highpc=0x56>DW_OP_breg5+8
> *
>
> Please explain briefly.
>
>
>
> Regards
>
> Neeraj
>
> On Jan 22, 2008 12:50 AM, David Anderson <davea42 at earthlink.net> wrote:
>
>   
>> Neeraj kushwaha wrote:
>>     
>>> Hi All,
>>>
>>> I am trying to find the location and value of local variable in a stack
>>> frame from the core dump.
>>> As GDB can fetch the value and location of local variable using the
>>> information from the dwarf debugging format.
>>>
>>> I am trying to manually find the location and value of the local
>>>       
>> variable
>>     
>>> from the core.
>>>
>>> This is what i did; from the a.out, I extracted the dwarf information
>>>       
>> using
>>     
>>> "dwarfdump -a a.out"
>>>
>>> and using the GDB i am trying to print the dump from the core "x/88b
>>>       
>> main1"
>>     
>>> But I am not able to find the location information of the local variable
>>>
>>> for example:
>>>
>>>         DW_AT_name                  c
>>>         DW_AT_decl_file             1 /home/neeraj/4.c
>>>         DW_AT_decl_line             15
>>>         DW_AT_type                  <177>
>>>         DW_AT_location              DW_OP_fbreg -20
>>>
>>>
>>> local variable is at location DW_OP_fbreg - 20. But how to find the
>>> DW_OP_fbreg?
>>>
>>>
>>>       
>> Look back a few lines.  The fbreg is defined in the subprogram
>> DIE (DW_AT_frame_base):
>>
>>     
>>> <1><  315>    DW_TAG_subprogram
>>>         DW_AT_external              yes(1)
>>>         DW_AT_name                  main
>>>         DW_AT_decl_file             1 /home/neeraj/4.c
>>>         DW_AT_decl_line             14
>>>         DW_AT_type                  <177>
>>>         DW_AT_low_pc                0x8048398
>>>         DW_AT_high_pc               0x80483ca
>>>         DW_AT_frame_base            [
>>> 0]<lowpc=0x24><highpc=0x28>DW_OP_breg4+4
>>>                     [ 1]<lowpc=0x28><highpc=0x2e>DW_OP_reg1
>>>                     [ 2]<lowpc=0x2e><highpc=0x2f>DW_OP_breg4+4
>>>                     [ 3]<lowpc=0x2f><highpc=0x31>DW_OP_breg4+8
>>>                     [ 4]<lowpc=0x31><highpc=0x56>DW_OP_breg5+8
>>>
>>>       
Two quotations from the dwarf specification should help:

1. DW_OP_fbreg
The DW_OP_fbreg operation provides a signed LEB128 offset from
the address specified by
the location description in the DW_AT_frame_base attribute of the
current function. (This is
typically a ?stack pointer? register plus or minus some offset.
On more sophisticated systems
it might be a location list that adjusts the offset according to
changes in the stack pointer as
the PC changes.)

And from an example in the spec:

DW_OP_fbreg -50
Given an DW_AT_frame_base value of ?DW_OP_breg31 64,? this example
computes the address of a local variable that is -50 bytes from a
logical frame pointer that is computed by adding 64 to the current
stack pointer (register 31).

So depending on where you are in the function one of the frame base rules
applies. Apply that rule, then the value involved is the fbreg.

Your variable had:

DW_AT_location              DW_OP_fbreg -20  

so the actual location is that frame base -20.


Hope this helps.
DavidAnderson




From ctice@apple.com  Wed Jan 23 22:54:49 2008
From: ctice@apple.com (Caroline Tice)
Date: Wed, 23 Jan 2008 14:54:49 -0800
Subject: [Dwarf-Discuss] PROPOSAL: Constant expressions in location lists
In-Reply-To: <4782DEE8.50508@sun.com>
References: <20080104212847.GD6849@redhat.com>
	<8f2776cb0801052329m21b54d6ftf6b5223ae71ab54b@mail.gmail.com>
	<20080106075926.E588F26F9A3@magilla.localdomain>
	<8f2776cb0801060117t415f623do3dc2a75d6c78868@mail.gmail.com>
	<478114D7.7000009@eagercon.com>
	<8f2776cb0801061726w41ee8be5p3456f041a9ba157b@mail.gmail.com>
	<47819EA1.6010704@eagercon.com>
	<8f2776cb0801071529t2b3e9b3emf2fcaaac4123b527@mail.gmail.com>
	<4782BF9B.8080600@sun.com> <4782C446.1020300@eagercon.com>
	<4782DEE8.50508@sun.com>
Message-ID: <100F269A-E1B9-4C78-B540-A533F72135FA@apple.com>



I've been following this discussion with great interest, as I work
largely in the area of trying to get debuggers (particuarly gdb) to
work "reasonably well" on optimized code (particularly the output from
gcc).

One extremely frustrating problem we run into a lot is that users will
ask to see variables that MUST be there somehow (otherwise the
computation could not be occurring), but gdb insists they are not.
The reason is that the compiler has transformed these variables in
such a way that (currently) there is no way to tell the debugger how
to access these variables.

The two most common cases I have run across are

1).  Given a for-loop of the kind:

      for (i = 0; i < 10; i++) {...}

      gcc converts the loop index variable so that instead of
      counting up from 0 to 9, it counts down from 9 to 0. (It does
      this by using a special register and a special instruction,
      which speeds things up a bit).

  When watching the code execute, the user KNOWS that the loop index
variable has to be around somewhere, but "i" as such has been
optimized away.  In this case it would be nice if DWARF allowed the
compiler to state "reconstruct i by getting the value of such-and-so
register and subtracting that value from 10".  Notice in passing, that
Jim Blandy's suggestion of representing source language expressions is
not helpful in this case because source languages don't let you
specify/access particular registers.  Using the suggestions from some
of the previous emails this might look something like:

        DW_OP_lit10 DW_OP_regx 47  DW_OP_minus  DW_OP_computed_value

2).  Given a boolean/flag variable, you might have some code of the  
form:

      flag = some_function_call ();

      if (flag)
        { ... }
      else
        { ... }

Again, it is obvious that the flag variable's value must be around
somewhere, (especially at the line containing the "if"), but it's
usually not available.  In this case, what gcc usually does is to
compare the result of "some_function_call ()" against 0, and store the
result of the comparison in a special register.  This presents a more
complex problem, because the debugger really can't tell the user the
value of "flag".  But what it *could* tell the user (assuming DWARF
gave it the necessary tools) is something along the lines of:

     (gdb) print flag
      Exact value unavailable.  "flag > 0" is true.

      (or "flag > 0 is false" or whatever the comparison is that
      the compiler actually performed).

This could be represented by something like:

     DW_OP_lit 0 DW_OP_gt DW_OP_regx 51  DW_OP_comparison_value

     where "DW_OP_lit0" is the value against which the
                         compiler performed the comparison,
           "DW_OP_gt" is the type of comparison the compiler performed
           "DW_OP_regx 51" is where the result of the comparison is  
stored
           "DW_OP_comparison_value" marks this as a non-exact value,  
namely
                         the result of a comparison.  Perhaps
                         "DW_OP_indirect_value" would be better?


I am not proposing this as the exact DWARF representation to use; it's
just a rough idea of what I need.

I am sure that there are far more cases where having DWARF be able to
reconstruct (or partially reconstruct) values that the compiler has
transformed or optimized away would be very useful.  These are just
two examples of my most pressing needs, and something for the
committed to consider when (if) they consider an extension to allow
specifying variables that optimizations have made not directly
available.

Since none of the previous discussions on this topic included cases at
all like these, I wanted to point them out.


--  Caroline Tice
ctice at apple.com






From roland@redhat.com  Thu Jan 24 03:07:47 2008
From: roland@redhat.com (Roland McGrath)
Date: Wed, 23 Jan 2008 19:07:47 -0800 (PST)
Subject: [Dwarf-Discuss] PROPOSAL: Constant expressions in location lists
In-Reply-To: Caroline Tice's message of  Wednesday,
	23 January 2008 14:54:49 -0800
	<100F269A-E1B9-4C78-B540-A533F72135FA@apple.com>
References: <20080104212847.GD6849@redhat.com>
	<8f2776cb0801052329m21b54d6ftf6b5223ae71ab54b@mail.gmail.com>
	<20080106075926.E588F26F9A3@magilla.localdomain>
	<8f2776cb0801060117t415f623do3dc2a75d6c78868@mail.gmail.com>
	<478114D7.7000009@eagercon.com>
	<8f2776cb0801061726w41ee8be5p3456f041a9ba157b@mail.gmail.com>
	<47819EA1.6010704@eagercon.com>
	<8f2776cb0801071529t2b3e9b3emf2fcaaac4123b527@mail.gmail.com>
	<4782BF9B.8080600@sun.com> <4782C446.1020300@eagercon.com>
	<4782DEE8.50508@sun.com>
	<100F269A-E1B9-4C78-B540-A533F72135FA@apple.com>
Message-ID: <20080124030747.29BDC26F9FD@magilla.localdomain>

Your example #1 is precisely the kind of case we have been discussing
(among others).  I believe the two proposals for this still on the table
are DW_OP_value and DW_AT_value.  Both are means to express that some
portion of a target-format value are not available at any location but can
be computed by a DWARF expression (one that yields precise bits to make up
the value in target format).  I don't think either of them has been written
up formally with proposed text for the standard.  (DW_OP_value is the best
name yet for the same meaning that DW_OP_computed_value has in the example
you showed.  DW_AT_value is an alternative way to encode the same
information as parallel to DW_AT_location rather than embedded in it, and
is backward-compatible with old consumers that don't know the new op.)

Your example #2 is something I don't think we have discussed directly
before.  That is, situations when it is not possible to reconstruct the
actual value but it is still possible to reconstruct constraints on what
the value might have been that may be useful to the debugger/user.  I do
see the motivation for addressing this situation too, though I find it a
lot less compelling.  Mostly that's because it is a bit hard to see how to
represent very many cases such that a debugger could do much with them.  I
did not get a very clear and precise idea from the formulation you gave.
I take the suggestion to be a way to express "I can't compute the value,
but I can compute the veracity of this particular assertion about the value".  

My skepticism about this notion relates to the general case of what
"value" means here.  As we've established in the responses to Jim Blandy's
contrary suggestion, the values we are talking about here are bit patterns
in target format that make up parts of the representation of source-level
objects.  In the simple cases like unsplit integer variables, a location
expression describes only one piece, and it is very simple to associate
what it describes with the interesting source-level concept to tell the
user about.  In those cases, an arithmetic assertion about the value is
easy to express and easy for the debugger to make useful to humans.  In
the general case, it seems far less feasible.

The way I would formulate what I take to be your idea is e.g.:

	DW_OP_lit0 DW_OP_breg5 DW_OP_gt DW_value_test DW_OP_piece(4)
	DW_OP_reg2 DW_OP_piece(4)

That says the 8-byte object's second four bytes are in register 2, and its
first four bytes are unavailable, but "register5 > 0" is a condition you
can evaluate to know something about the value of the first four bytes.
But what is it you are supposed to know about it?  How do you figure out
what that means about the source-level value?

The idea that I can get behind a little more is a "range of values" thing, e.g.:

	DW_OP_lit0 DW_OP_breg5 DW_OP_gt DW_OP_bra(4)
		DW_OP_lit0 DW_OP_value DW_OP_skip(7)
		DW_OP_lit1 DW_OP_const4u(0xffffffff) DW_OP_range DW_OP_piece(4)
	DW_OP_reg2 DW_OP_piece(4)

That says the first four bytes have a complex derivation.  If register5 <= 0,
then the value is known to be exactly zero (DW_OP_value fork).  If instead
register5 > 0 (DW_OP_bra triggers), then what we know is that the four bytes
have a bit pattern in the range [1,0xffffffff] (upper and lower bounds popped
off the stack).  For multiple disjoint ranges, there could be multiple
DW_OP_range clauses giving alternatives.

I made this example complex to bring in a new wrinkle that your suggestion
made me think of.  This is an issue that already exists (in theory) just with
location vs value, even before considering the "fuzzy value" ideas.  That is,
when it's not just that separate PC ranges differ in whether it's a location
that's available, or a value that's available, or neither.  Here, a dynamic
program value (an expression computing from a machine register) decides
whether there is a computed exact value or a known range of possible values.
In the example above I addressed this with a subtle varation on how we've
described DW_OP_value in the past.  That is, here DW_OP_value is not just a
trailing marker of a special kind of expression.  Rather it is a proper
operation, executed or not by the expression's dynamic control flow, that
says "complete the piece now as having the top of stack as computed value".

To allow this kind of dynamic selection, it would also make sense to have a
DW_OP_no_value or some such, to indicate the situation where no information
at all is available.  In static cases, that situation is represented by an
empty expression before DW_OP_piece (or a whole expression that is empty or
just omitted completely).  DW_OP_value on stack underflow seems like a bad
thing to specify, so DW_OP_no_value, or perhaps DW_OP_unavailable, makes sense.

All of that is quite rough.  But it seems like it might be worth considering
the dynamic-selection cases, contemplate how a compiler would produce these
things, and whether it's worth being able to express that.

I do also think that the "fuzzy values" area has some merit.  I think ideas
based on ranges of bit values are probably more useful than ideas based on
describing predicates of some sort.  It's just a lot easier to imagine how a
debugger putting together the target format value and then interpreting how
to show that to a user could find coherent things to say when it's looking at
a representation of "runs of known bits, runs of unknown bits, and runs of
bits in known ranges".  Maybe I would find a predicate-based idea as
compelling if it were thoroughly fleshed out and explained to me.


Thanks,
Roland



From marcelm@altium.nl  Mon Jan 28 12:50:28 2008
From: marcelm@altium.nl (Marcel Mettes)
Date: Mon, 28 Jan 2008 13:50:28 +0100
Subject: [Dwarf-Discuss] DW_AT_specification in C++ classes
Message-ID: <479DCF94.6090106@altium.nl>

Hello,

We have three questions that all stem from the use of
DW_AT_specification in C++ class debug info constructs.

  1. Is this example a proper C++ class representation in DWARF?
  2. Is there an alternative representation available?
  3. Hide DIEs explicitly using a new attribute

1.Is this example a proper C++ class representation in DWARF
------------------------------------------------------------

We are considering cases where not 2 DIEs are used that are
connected via DW_AT_specification, but a chain of 3 DIEs.

Example:

    offset  DIE
    X1      DW_TAG_namespace
    X2      +- DW_TAG_class_type
    X3         +- DW_TAG_subprogram (at offset X3)
    X4            +- DW_AT_name "foo"

    ...

    offset  DIE
    Y1      DW_TAG_subprogram
    Y2      +- DW_AT_specification (points to (X3))

    ...

    offset  DIE
    Z1      DW_TAG_subprogram
    Z2      +- DW_AT_specification (points to (Y2))
    Z3      +- DW_AT_low_pc              value = 0x00000044
    Z4      +- DW_AT_high_pc             value = 0x0000004C
    Z5      +- DW_AT_frame_base          value = [location list]

This setup stems from the combining of all debug information from
the various stages along the tool-chain.

Is this an appropriate form to use for C++ class debug info?
We are wondering if already existing debuggers will be able to
both interpret it and use it.

2.Is there an alternative representation available?
----------------------------------------------------

Given the example in question 1 we are wondering if other debuggers
will be able to both interpret it and use it.

The 2 DW_AT_specification links may require extra code to be
added to existing debugger to convey the actual semantics of
the construct.

Hence we wonder, is there an already accepted or perhaps
even canonical form to represent C++ classes in DWARF 3 using
DW_AT_specification to construct class member debug info?  One that
can be interpreted by existing debuggers without
no or minor modifications?

3. Hide DIEs explicitly using a new attribute
---------------------------------------------

The use of DW_AT_specification brings with it the adding of DIEs
that have no meaning by themselves. However, if a linker happens
to place a DW_AT_name inside such an augmentation DIE, it may
show up as symbol in the debugger symbol browser, even though it
is not a symbol.

One could use the presence of DW_AT_spefication as a flag telling
to hide that DIE. Sort of like DW_TAG_imported_unit" (which is
described in Section 3.1.2 as "merely glue"), but for individual
tags? Or is DW_AT_specification supposed to be that glue?

This is not possible we think, since DW_AT_specification is also
used for linking e.g. C variable declarations to the real, global,
variable (see DWARF 3, par. 4.1, sub 6). In those cases the DIE
containing the DW_AT_specification must not be hidden in order to
enable the debgger to find that symbol in the scope it is in.

One can use the assumption that in all DIEs, except DIEs
with DW_TAG_variable/DW_TAG_formal_parameter/DW_TAG_constant,
the presence of an DW_AT_specification is to be interpreted as
marking the DIE as hidden, but that is not clearly stated as such
in the DWARF 3 definition. Hence it may change in the future which
TAGs/DW_AT_specification combinations are hidden or not.

One can look at the DW_AT_specification DIEs as augmenting DIEs,
provided to enable implementors of compilers, assemblers and
linkers to pour the debug info into DWARF form, by combining them
via DW_AT_specification from multiple sources, into a meaningful
set of DIEs.

The question we have is: is it perhaps possible to flag DIEs that
are only used to augment other, defining, DIEs as hidden with an
attribute specific for this task?

Best regards,
Marcel Mettes

********************************************
Altium - Unified PCB/FPGA/C/C++ EDA Tools
http://www.altium.com
********************************************





