From ccoutant@gmail.com  Tue Jun  5 07:46:15 2007
From: ccoutant@gmail.com (Cary Coutant)
Date: Tue, 5 Jun 2007 00:46:15 -0700
Subject: [Dwarf-discuss] PROPOSAL: Constant expressions in locations
	lists
In-Reply-To: <20070530022649.8174D1F8511@magilla.localdomain>
References: <20070530022649.8174D1F8511@magilla.localdomain>
Message-ID: <5979EF02-12E6-4293-AE91-93D36F712278@gmail.com>

> This was moved to the private mailing list and it doesn't look like  
> there
> has been any traffic about it for a while.  So I don't know what  
> its status is.
> I think the formulation should be adjusted a little from what was  
> proposed.
>
> The block is often overkill, but I think adding a plethora of
> constant_value[248] and so forth would be a waste of opcodes and  
> needless
> new repetition in decoding.  Instead, I suggest using a special suffix
> operation DW_OP_implicit_value.  It can follow DW_OP_const*,  
> DW_OP_lit*, etc.

My original proposal was (almost) exactly that, but several objected  
to that proposal on the basis that the DWARF expression stack is a  
simple stack of address-sized objects. Without a considerable  
overhaul of the DWARF expression language, it wouldn't be possible to  
describe constant values for anything other than integers no larger  
than a pointer. The new formulation sacrifices this ability to  
rematerialize a value for the ability to represent constant values of  
arbitrary type.

-cary






From roland@redhat.com  Tue Jun  5 08:14:44 2007
From: roland@redhat.com (Roland McGrath)
Date: Tue,  5 Jun 2007 01:14:44 -0700 (PDT)
Subject: [Dwarf-discuss] PROPOSAL: Constant expressions in locations
	lists
In-Reply-To: Cary Coutant's message of  Tuesday, 5 June 2007 00:46:15 -0700
	<5979EF02-12E6-4293-AE91-93D36F712278@gmail.com>
Message-ID: <20070605081444.BB2FC4D058E@magilla.localdomain>

> My original proposal was (almost) exactly that, but several objected  
> to that proposal on the basis that the DWARF expression stack is a  
> simple stack of address-sized objects. Without a considerable  
> overhaul of the DWARF expression language, it wouldn't be possible to  
> describe constant values for anything other than integers no larger  
> than a pointer. 

That's not true.  You can use DW_OP_piece (my proposal gave an example of a
two-word array described that way).  It's entirely possible, though I
readily concede that it is awkward.  (Also note that neither the status quo
nor the previous proposal allows a representation for an array or struct
that is partly constant and partly in described locations, as I propose
permitting via DW_OP_piece.  That is really an orthogonal generalization
that could be applied to the block-constant specialty location expression too.)

> The new formulation sacrifices this ability to rematerialize a value for
> the ability to represent constant values of arbitrary type.

The proposal is presumably motivated by some real-world cases.  Are there
in fact real-world cases where an address-variant value is sometimes a
constant that is very large, so that the DW_OP_piece method would be
inordinately ungainly?  I don't doubt such constants exist, but I would be
surprised by the real-world examples of them arising in a variable in some
address ranges but not others.  DW_AT_const_value already suffices for
large constants when a location list is not required.

I am not especially against a block-constant specialty location expression.
(I'm not convinced it's worthwhile to have a plethora of special-case
short-length operations as well as the general ULEB128 block form, it's
only an extra byte or two.)  It seemed like a good opportunity to kill two
birds with one stone (three if you count DW_CFA_val_expression).  My guess
is that rematerializable values are a more common real-world scenario that
would be useful to support than large constants in location subsets are a
common real-world scenario that matters to support gracefully (vs with some
discomfort and suboptimality using DW_OP_piece).


Thanks,
Roland



