This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v3] Enable tracing of pseudo-registers on ARM
- From: Pedro Alves <palves at redhat dot com>
- To: Antoine Tremblay <antoine dot tremblay at ericsson dot com>
- Cc: gdb-patches at sourceware dot org, qiyaoltc at gmail dot com
- Date: Wed, 24 Feb 2016 18:11:06 +0000
- Subject: Re: [PATCH v3] Enable tracing of pseudo-registers on ARM
- Authentication-results: sourceware.org; auth=none
- References: <wwoklh6gpsne dot fsf at ericsson dot com> <1455910116-13237-1-git-send-email-antoine dot tremblay at ericsson dot com> <56C7796B dot 3030504 at redhat dot com> <wwokoab8it8q dot fsf at ericsson dot com>
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