This is the mail archive of the gdb-patches@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: For review: delete write_fp() and TARGET_WRITE_FP()


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]