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: Antoine Tremblay <antoine dot tremblay at ericsson dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Antoine Tremblay <antoine dot tremblay at ericsson dot com>, <gdb-patches at sourceware dot org>, <qiyaoltc at gmail dot com>
- Date: Mon, 22 Feb 2016 11:51:01 -0500
- 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>
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 ?
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.
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)? And that it is set to use tdesc
registers (so that gdbarch_remote_register_number maps to
tdesc_remote_register).
Thanks,
Antoine