Re: RFC: implement DW_OP_bit_piece

Tom Tromey
2010-05-20T06:21:53Z

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