Re: RFC: implement DW_OP_bit_piece

[Stan Shebs <stan@codesourcery.com>]

Tom Tromey wrote:
> I am less sanguine about updating the tracepoint code, I suppose because
> it is pretty new and yet doesn't implement even what was already in gdb
> when it went in:
>
> 	  if (bytes != 4)
> 	    error (_("DW_OP_piece %s not supported in location for \"%s\"."),
> 		   pulongest (bytes), SYMBOL_PRINT_NAME (symbol));
>   

Touche'  :-)

> I did dig around in the code a little, and it turns out I'm also not
> clear on all the details I would need to implement the support.
>
> I don't really see how DWARF expressions can work with the current
> setup.  Maybe just some subset can -- but then I would like to
> understand how the subset is chosen, I guess so I can argue against
> choosing DW_OP_bit_piece ;-).  Ok, seriously...
>
> For instance, I don't understand how a DWARF expression involving a
> conditional could work.  You could compile DWARF to AX, including the
> condition.  But then I think you'd have to circumvent the DWARF
> expression when re-evaluating the expression at "replay" time (I don't
> know the real name of the mode, sorry).
>
>   

In theory, evaluation of the expression while examining a trace frame 
will just work, because the DWARF condition will evaluate to the same 
value as it would have when looking at the live state.

> GCC is already emitting nontrivial DWARF.  It can emit some stack ops
> (look at the MOD case in dwarf2out.c).  It can emit pieces and stack and
> literal values.  And, I think it can emit TLS references.  So this is
> not just hypothetical, today's expression translation is already
> insufficient for today's GCC.
>   

We've been special-casing things in the ax code as they've come along in 
real compiler output - your mention of bit pieces got my attention 
because it sounded like tracepoint test cases could start regressing if 
someone updated their GCC.

But yeah, this is the kind of thing that gets us to start muttering 
again about the common compilation / evaluation pathway idea.  
CodeSourcery's tracepoint work has already been decided for this year, 
and the closest related task is going to be some better handling of 
partially-collected values.  But now is a good time to start thinking 
about what we should do in 2011; I can see things getting to the point 
where the common pathway is the easiest strategy for coping with 
ever-more-complex debug info from GCC.

Stan