This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH] Bug 20936 - provide sparc and sparcv9 target description XML files
- From: Ivo Raisr <ivo dot raisr at oracle dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Yao Qi <qiyaoltc at gmail dot com>, gdb-patches at sourceware dot org
- Date: Wed, 25 Jan 2017 17:05:10 +0100
- Subject: Re: [PATCH] Bug 20936 - provide sparc and sparcv9 target description XML files
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com> <20161206152616.GC28789@E107787-LIN> <firstname.lastname@example.org> <email@example.com> <20161212125331.GB25542@E107787-LIN> <firstname.lastname@example.org> <20170105143109.GA21293@E107787-LIN> <email@example.com> <firstname.lastname@example.org>
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:
2017-01-06 Ivo Raisr <email@example.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
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.