[PATCH v3] Enable tracing of pseudo-registers on ARM

[Pedro Alves]

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?


 And that it is set to use tdesc
> registers (so that gdbarch_remote_register_number maps to
> tdesc_remote_register).

Thanks,
Pedro Alves