On 02/22/2016 04:51 PM, Antoine Tremblay wrote:
Pedro Alves writes:
Hmm, seems to me that gdb raw -> target raw mapping should be
either here, or perhaps even in ax_reg / ax_reg_mask?
Consider the case of an expression requiring the collection of
a _raw_ register, thus not even reaching here. Looking at
ax-gdb.c/ax-general.c I don't see where is anything mapping gdb raw numbers
to remote/tdesc numbers? So how does _that_ work? Are the register masks that gdb
is computing actually wrong for the target, and things just happen
to work because gdbserver ignores them and always collects all registers?
Is there a good reason gdbserver actually ignores that ?
I don't recall any, other than collecting everything is expedient
and good enough...
It seems all the code is there for it to consider it on gdb's
side. encode_actions, stringify_collection_list etc... The only thing
missing seems to be gdbserver interpretation of the R action.
Right. Obviously you'd need to consider how to represent the
partial register set in the trace frame as well. Just marking
some registers as unavailable while still crafting a whole register
block in the trace buffer is pointless, obviously.
While looking at fixing this for all the archs involved it would be
much simpler to test if gdbserver would make use of it.
As it is now, I'm concerned that calling gdbarch_remote_register_number
in ax_reg, ax_mask_reg could break things if the arch already considers
the gdb raw -> target raw mapping like s390 and x86 do already (I'm not
100% sure the mapping is already ok)?
WDTM? Where do they do this already?