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

["Marcin Kościelnicki" <koriakin@0x04.net>]

On 24/02/16 19:11, Pedro Alves wrote:
> 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?

FWIW, I failed to look at the numbering used when I wrote the x86 and 
s390 ax functions, so they're most likely wrong (I just copied the 
regnum computation logic from pseudo_read/write, which uses gdb 
numbers).  s390 hasn't landed yet, so it's only x86 that you'd have to 
fix now (and mips, I think, but that doesn't support tracepoints yet...).

Testing this is possible if you write some conditions that involve 
reading pseudo-registers (since ax_pseudo_register_push_stack will be 
called), the problem is that I only implemented 
ax_pseudo_register_collect for x86...

Are you going to make some higher-level patch that will magically fix it 
for my s390 patch, or do I have to fix that on my own?
>
>
>   And that it is set to use tdesc
>> registers (so that gdbarch_remote_register_number maps to
>> tdesc_remote_register).
>
> Thanks,
> Pedro Alves
>