Re: RFC: implement DW_OP_bit_piece

[Tom Tromey <tromey@redhat.com>]

Tom> But it seems like this can probably be done without that.  Though, I
Tom> haven't looked enough at ax.h to know whether it can represent all of
Tom> DWARF... which reminds me, how much trouble is it to add to AX?  Is it
Tom> versioned so we can detect old remotes?

I looked a little.

I didn't see explicit versioning in the agent expressions but I gather
from remote.c that we could add a new remote feature and query it.

I looked at DWARF->AX translation.  I see how most of it can be done,
except:

DW_OP_implicit_value can be arbitrarily wide.  It seems strange to even
want to upload a constant, but this could be used as part of a bigger
expression.  However in practice it is probably ok.

Some stack ops are missing: DW_OP_pick, DW_OP_rot, DW_OP_over.
I think 'over' is emitted by gcc, but maybe we could recognize the
particular bytecode sequence and generate a signed modulus directly.
(Yuck.)

DW_OP_call_frame_cfa seems to require some gyrations, I didn't trace all
the way down to see if it is reasonably possible.

DW_OP_GNU_push_tls_address.  Maybe possible, but I don't know enough.

DW_OP_piece and DW_OP_bit_piece.  These are problems in some contexts,
but not others.  A few cases I've considered:

* As the terminus of a trace expression they ought to be ok.  This means
  a simple expression, like a variable, which is made of pieces.  In
  this case I think we can probably trace the various parts and discard
  each result until the final one.

* They might be ok as part of an aggregate which is then "sliced" at a
  constant offset.  So, something like "struct.field" or "array[5]".
  However, I think they are not ok, or at least difficult to compile, if
  the expression is something like "array[i]".  Even the possible case
  here will probably lead to ridiculous bytecode in some cases.

Tom