[Dwarf-Discuss] PROPOSAL: DW_OP_implicit_pointer

[Ron Brender]

Ah ha but, but, but...

Sorry for that last--I think I now understand (better) the problem to be 
solved. But now I don't see how DW_OP_implicit_pointer helps solve that 
problem. In particular, the proposal definitely needs an example or two 
to illustrate just how it is used. That is, it needs (read I need to 
see) a source, a summary of the key code generation decisions and the 
corresponding DWARF.

A key confusion for me is just where this new operator is used. It seems 
like it can't be of interest in the type description for a struct/class 
or any of its members because the information to be conveyed is specific 
to each object (variable/const) of that type. But then I can't see how 
it might be used in the location description of a variable in a way that 
  relates to the variable's type. Me thinks there is an implied debugger 
processing algorithm here that I am just not seeing.

Finally, as described, it appears that this operator neither uses any 
values that are expected to be on the DEBUG stack nor has any effect 
(pushes/pops/whatever) on the DEBUG stack--is that correct?

Ron

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

Jakub Jelinek wrote:
> On Thu, Aug 12, 2010 at 09:54:40AM -0400, Ron Brender wrote:
>> In reviewing the proposal I feel unclear regarding what problem it
>> is intended to solve.
>>
>> If I understand correctly, the effect of this operator is equivalent
>> to replicating the DW_AT_location or DW_AT_const_value of the
>> referenced DIE followed by an DW_OP_add operation using the second
>> parameter. Is this a correct understanding.
>>
>> If so, it appears that the primary intended benefit is a space
>> saving by avoiding replication of potentially large _location or
>> _const_value attributes.
>>
>> If I have got it all wrong, please clarify.
> 
> No, this isn't something that can be expressed currently in DWARF4.
> 
> Consider:
> 
> struct S
> {
>   int *x, y;
> };
> 
> int u[6];
> 
> static inline void
> add (struct S *a, struct S *b, int c)
> {
>   *a->x += *b->x;
>   a->y += b->y;
>   u[c + 0]++;
>   a = (struct S *) 0;
>   u[c + 1]++;
>   a = b;
>   u[c + 2]++;
> }
> 
> int
> foo (int i)
> {
>   int j = i;
>   struct S p[2] = { {&i, i * 2}, {&j, j * 2} };
>   add (&p[0], &p[1], 0);
>   p[0].x = &j;
>   p[1].x = &i;
>   add (&p[0], &p[1], 3);
>   return i + j;
> }
> 
> int
> bar (int i)
> {
>   int *j = &i;
>   int **k = &j;
>   int ***l = &k;
>   i++;
>   return i;
> }
> 
> An optimizing compiler will likely optimize away all the pointers
> and the variables that had address taken (like i, j, k) might
> be also optimized away (have just implicit location descriptions)
> or not be addressable (live in registers).  Variable p might also
> be scalarized and the different pieces kept in different registers.
> 
> When the object, to whose address the optimized away pointer points
> to, is not addressable, with DWARF4 all the compiler can do is not
> emit DW_AT_location (nor DW_AT_const_value) at all.  With this extension
> e.g. in bar, while you can't print j's value, you can print *j.
> Similarly in the inlined add calls you can print *a->x, a->y, *b->x, b->y
> or in foo print say *p[0].x.
> 
> 	Jakub
> 
>