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

[Marcin KoÅcielnicki <koriakin at 0x04 dot 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