This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Bug 20936 - provide sparc and sparcv9 target description XML files
On 01/25/2017 04:05 PM, Ivo Raisr wrote:
>
>
> On 25.1.2017 16:46, Pedro Alves wrote:
>> (I know I'm quite behind this thread.)
>>
>> On 01/06/2017 03:12 PM, Ivo Raisr wrote:
>>>
>>> ChangeLog entry:
>>> 2017-01-06 Ivo Raisr <ivo.raisr@oracle.com>
>>>
>>> Split real and pseudo registers in preparation for registers
>>> provided
>>> by a target. Registers provided by target description can have
>>> more real
>>> registers and pseudo registers need to be positioned after them.
>>
>> I don't quite understand this rationale, and I'm wondering if there's
>> a misunderstanding of register numbering somewhere (maybe mine!).
>>
>> What exactly would go wrong if you just added the new registers
>> between the existing raw and pseudo registers? Other ports do
>> that routinely.
>
> Good question.
> The rationale is target provided registers.
> Consider a typical Valgrind use case where target (gdbserver stub
> implemented inside Valgrind) supplies 3 times more raw registers than
> the architecture normally supports.
> One set mimics the "normal" registers, the other two sets are shadow
> copies used internally by Memcheck tool to keep track of
> defined/undefined bits and their origins.
>
> So when gdb'ing ordinary process, you have:
> - raw registers (one set)
> - pseudo registers
>
> However when gdb'ing Valgrind'ed process over gdb remote protocol
> with --vgdb-shadow-registers=yes, target provides:
> - first set of raw registers (describes guest state)
> - second set of raw registers (describes the first shadow copy)
> - third set of raw registers (describes the second shadow copy)
> - pseudo registers (actually provided by gdb)
>
> So this means pseudo registers numbering must be flexible.
> Other targets (such as s390x, aarch64, amd64) do it in similar ways.
Ah, OK. I see what you're doing now. Thanks for clarifying!
Thanks,
Pedro Alves