Re: [PATCH] Bug 20936 - provide sparc and sparcv9 target description XML files

[Pedro Alves <palves@redhat.com>]

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