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

Pedro Alves
2016-02-24T18:11:10Z

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