This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH]: Fixes for pseudo regs support
- To: Stephane Carrez <Stephane dot Carrez at worldnet dot fr>
- Subject: Re: [PATCH]: Fixes for pseudo regs support
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Thu, 01 Mar 2001 14:07:43 -0500
- Cc: gdb-patches at sourceware dot cygnus dot com
- References: <39A5B4A7.8261D654@worldnet.fr> <3A06ACF1.AA32DF9C@cygnus.com> <3A1AFD72.1CA9B1AB@worldnet.fr>
Ref: http://sources.redhat.com/ml/gdb-patches/2000-08/msg00305.html
Stephane Carrez wrote:
> > Lets consider a hypothetical architecture with N real registers
> > (r[0]..r[N]) and M pseudo registers (p0..pN). Each pseudo register is
> > contructed using something from all the real registers vis:
> >
> > p[i] == pseudo (i, r[0], r[1], ...)
> >
>
> It is not my case. The pseudos are not constructed from real registers.
Ok, I now understand.
At present we've got something like:
p[i] == pseudo (i, raw_registers, memory)
and p[i] == pseudo (i, frame->saved_regs[0..NUM_RAW], raw_registers,
memory)
In a separate e-mail I've proposed that these be consolidated into a
single:
cooked_{read,write} (i, frame, ®)
where a frame might have raw-registers, memory, architecture, local
state along with a chain frame chain. This change would address your
problem since ``local state'' could contain anything.
The patch you've proposed extends saved_regs[] so that it includes space
for pseudo registers. Doing that makes it possible for an architecture
that saves entire raw pseudo registers on the stack to specify their
location using saved_regs[].
Significantly, it doesn't fix the more generic problem of a frame's
pseudo register being constructed from random information found on both
the stack and in the raw register buffer.
A simple example of this might be a 64 bit pseudo register that is
constructed from 32bit offset register (saved on stack) and a 64 bit
base register (in the register cache).
I'll check your patch in but add comments pointing out its limitations
and how gdb needs to be changed before those limitations can be
addressed.
Andrew