From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: David Taylor Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] regcache.c (register_fetched) + related changes Date: Fri, 02 Mar 2001 11:49:00 -0000 Message-id: <3A9FF8B5.E88307BD@cygnus.com> References: <200103020058.TAA18595@texas.cygnus.com> X-SW-Source: 2001-03/msg00042.html > 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