This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] regcache.c (register_fetched) + related changes
- To: David Taylor <taylor at cygnus dot com>
- Subject: Re: [RFA] regcache.c (register_fetched) + related changes
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Fri, 02 Mar 2001 14:47:01 -0500
- Cc: gdb-patches at sources dot redhat dot com
- References: <200103020058.TAA18595@texas.cygnus.com>
> Example, for this processor, the frame pointer is a pseudo register.
> The frame pointer is two random 8 bit registers -- 16 bits. The
> hardware does *NOT* have the ability to operate on those registers as
> a pair. It cannot load the frame pointer, it cannot store the frame
> pointer, it can only load or store one of the 8 bit registers at a
> time.
>
> Since the compiler writer simply chose two adjacent 8 bit registers,
> in the right order, there is no need, in REGISTER_BYTES to have a
> special place for the fp and then copy things back and forth --
> instead the value goes directly into the two underlying real
> registers.
>
> So, when the fp is fetched, there is a need to mark the underlying
> real registers (i.e., registers in the range [0,NUM_REGS) as fetched.
Yes.
That is a design flaw in the way GDB currently handles FP and other
pseudo registers. At first sight you think that something like
write_pseudo() can be implemented as just:
read_register_gen(..., first half);
read_register_gen(..., second half);
Unfortunatly, because of some broken code in the core of gdb still also
need to allocate space in the regcache and pull all sorts of nasty
hacks.
The idea of separating a core-gdb register write from the raw register
cache (so that write_pseudo() can do a scatter. Should fix that. I was
planning on such a change as part of binding everything to a frame,
however, that could be separated out.
Andrew