Re: RFC: implement DW_OP_bit_piece

[Tom Tromey <tromey@redhat.com>]

>>>>> "Stan" == Stan Shebs <stan@codesourcery.com> writes:

Stan> Your code looks reasonable, but you're missing two, uh, pieces :-)  - 

Thanks.

Stan> the dwarf2_tracepoint_var_ref code to compile to bytecodes, and
Stan> human-readable description in locexpr_describe_location_1.

Stan> (Yes it's onerous, but we did want to revive tracepoints, right?)

I will update locexpr_describe_location_1.

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));

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).

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.

Tom