This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: For review: delete write_fp() and TARGET_WRITE_FP()
- To: Stan Shebs <shebs@cygnus.com>
- Subject: Re: For review: delete write_fp() and TARGET_WRITE_FP()
- From: Andrew Cagney <ac131313@cygnus.com>
- Date: Wed, 14 Jul 1999 16:35:31 +1000
- CC: gdb-patches@sourceware.cygnus.com
- Organization: Cygnus Solutions
- References: <199907131608.JAA17183@andros.cygnus.com>
Stan Shebs wrote:
> It would seem to me that the need to add a deprecated GDB_TARGET_IS_
> ifdef is your evidence of why write_fp needs to be part of the arch
> description...
Don't forget that this lone reference to write_fp() is in sparc-tdep.c -
it is refering to one of its own definitions and consequently could
easily be written in a cleaner way.
>
> if (strcmp (target_shortname, "sim") != 0)
> {
> ! #ifdef GDB_TARGET_IS_SPARC64
> ! sparc64_write_fp (old_sp);
> ! #else
> ! write_register (FP_REGNUM, old_sp);
> ! #endif
> As much as I like to get rid of useless code, I have mixed feelings
> about deleting this particular capability. Not only is there a
> symmetry argument - pc, sp, and fp are the three registers about which
> GDB must know and be able to handle specially - but systems with
> virtual frame pointers and such may need to define write_fp in the
> future. (Right now we don't need to because we define fake fp regs
> for the frame-pointer-less systems.)
What capability? :-)
Systems with virtual frame pointers end up doing the real work in the
INIT_EXTRA_FRAME_INFO macro. Looking at the source, that read_fp() has
just managed to confuse the poor coder - see MIPS where its cascaded
into the remote target where a T-packet response containing the
virtual-frame-pointer is sent back to GDB :-(
Broadly, I'm thinking that:
o That ``$fp'' virtual register has to
go. Something like ``$frame'' (?) and
that would map onto (struct frame_info)
->frame. That way people won't confuse
it with the real ``$fp'' when
that is part of an ISA - ref ARM.
Changing $frame might result in a rebuild
of the corresponding ``frame_info''.
o The way the frame_info object is
initialized needs a serious re-think.
o This ``frame handle'' and how it is
used (for things like unwinding a
stack) all needs a re-think.
Something to discuss next week.
enjoy,
Andrew