Re: DW_OP_piece and optimisations

[brender at gemevn dot zko dot dec dot com (Ron 603-884-2088)]

Keith Walker wrote:
>Take the following piece of code:
>
>	struct s {
>		int a;
>		int b;
>		int c;
>	};
>
>	int func (void)
>	{
>		struct s S;
>
>		S.b = 1;
>		return S.b;
>	}
>
>Suppose that the compiler has optimized this to put "S.b" into a register
>and optimized away "S.a" and "S.c".
>
>Would it be valid to use the DW_OP_piece operator with no preceding DWARF
>expression to indicate those parts of "S" which have been optimized away?

I don't see how. The location expression for S has to define a location,
but there is none that applies to S as a whole. The location expression
for member b has to define the location for the member based on the non-
location of the containing object in a way that applies to all objects of
the type s. I don't see how to get there from here with the tools that
DWARF makes available...

>So, for example, "S"'s location might be described by the location expression:
>
>	{
>		DW_OP_piece 4		! S.a optimized out
>		DW_OP_reg0 DW_OP_piece 4	! S.b in R0
>		DW_OP_piece 4		! S.c optimized out
>	}

>As far as I can see the relevant quotes from the Standard are:
>
>Section 2.5.2, Location Expressions
>	"An expression with zero operations is used to denote an object
>	 that is present in the source code but not present in the object
>	 code (perhaps because of optimization)."
>
>Section 2.4.1.6,Special Operations
>	"DW_OP_piece takes a single argument, which is an unsigned
>	 LEB128 number.  The number describes the size in bytes of the
>	 piece of the object referenced by the DWARF expression whose
>	 result is at the top of the stack."
>
>
>Is this a valid interpretation of the Standard to describe this situation
>or have I combined 2 quotes which are not intended to be combined?

I don't think they are intended to be combined.

>Is there a better way to describe this?

As I said, I don't see that there is any way at all.

>Or is there a requirement for a special DW_OP_ operation to describe an
>"optimized out" location?

Well, it does appear that there is an "opportunity" here but I don't see
a way offhand to go after it. It seems like somehow you want a variant
of a DW_AT_data_member_location attribute that applies to "real" objects
(not members of a type) and that identifies 1) the member that it goes with
and 2) the location expression for that member of the containing object.
Of course, you might need one for each member so there needs to be a
list of some kind. And you need to be careful to deal properly with
nesting (maybe a big deal, maybe not: I'd haven't thought it through).
All and all, probably a very non-trivial undertaking is my guess...