This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 3/4] Enable tracing of pseudo-registers on ARM
- From: Yao Qi <qiyaoltc at gmail dot com>
- To: Marcin KoÅcielnicki <koriakin at 0x04 dot net>
- Cc: Yao Qi <qiyaoltc at gmail dot com>, Antoine Tremblay <antoine dot tremblay at ericsson dot com>, gdb-patches at sourceware dot org
- Date: Mon, 15 Feb 2016 10:27:29 +0000
- Subject: Re: [PATCH 3/4] Enable tracing of pseudo-registers on ARM
- Authentication-results: sourceware.org; auth=none
- References: <1452188697-23870-1-git-send-email-antoine dot tremblay at ericsson dot com> <1452188697-23870-4-git-send-email-antoine dot tremblay at ericsson dot com> <86egcineq0 dot fsf at gmail dot com> <56BE002F dot 7050305 at 0x04 dot net>
Marcin KoÅcielnicki <koriakin@0x04.net> writes:
> I'd like to point out that this testcase is near-useless for testing
> ax_pseudo_register_collect or pseudo_register_to_register at the
> moment - while gdb computes a mask of what registers need to be
> collected, gdbserver just ignores it and collects all registers if any
> register at all is to be collected. In turn, gdb allows you to
> display the state of all registers, even ones not included in the
> mask. In fact, the tfile-avx.exp test passes just fine if you change
> it to collect any unrelated register. My commit with
> ax_pseudo_register_collect only made it work because gdb needs to have
> that function return success, the actual returned mask could just as
> well be wrong...
The usefulness I can think of is that GDB can check whether the pseudo
register exists to collect. User may want to collect Q registers, but
they don't exist on the target.
>
> The other hook, pseudo_register_push_stack, is much easier to test -
> it's invoked when a pseudo is used in an actual agent expression,
> eg. if you use it in a tracepoint condition, or as part of the address
> of collected memory area. However, it cannot be used on SIMD
> registers (at least on x86, I don't know much about arm), as they
> don't fit in an ULONGEST...
The same issue on both arm and aarch64, AFAIK.
>
> Matter of fact, our support for >64-bit quantities in tracepoints is
> very poor at the moment - they can only be collected wholesale when
> they're single registers or contig memory areas. Use in expressions
> is out (if you happen to have something interesting in low 32 bits of
> a vector reg, sorry). Likewise, stiching them together with
> DW_op_piece (or whatever that was called) also fails (see
> https://sourceware.org/bugzilla/show_bug.cgi?id=17015). We could
> definitely use some improvement there...
Yeah, agreed.
--
Yao (éå)