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

[Ivo Raisr <ivo dot raisr at oracle dot com>]

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.

Kind regards,
I.