Re: [rfa/doco] FRAME_FP -> read_fp

[Andrew Cagney <ac131313 at redhat dot com>]

> On Tue, 19 Nov 2002, Andrew Cagney wrote:
>
>
> > This patch updates the doco so that it better reflects GDB's current 
> > implementation of create_new_frame().
> >
> > ok?
>
> Ahm, what does this mean, exactly, "read_fp in the machine description"?  
> Isn't read_fp a function?  If so, how can it be present ``in the machine 
> description''?
regcache.c contains:

CORE_ADDR
read_fp (void)
{
  return TARGET_READ_FP ();
}

and TARGET_READ_FP() is part of the machine description (a.k.a. 
architecture vector).


> In case it isn't clear, I refer to this text:
>
>   +@code{read_fp} in the machine description has no meaning
The full text is:

> @findex create_new_frame
> @vindex read_fp
> @code{read_fp} in the machine description has no meaning to the
> machine-independent part of @value{GDBN}, except that it is used when
> setting up a new frame from scratch, as follows:
>
> @smallexample
> create_new_frame (read_fp (), read_pc ()));
> @end smallexample
And the only change I made was to update things to refer to read_fp() 
instead of FRAME_FP().  The description is correct.  As far as the 
machine independant code is concerned, read_fp() returns a magic number.

The text then goes on to mention:

> @cindex frame pointer register
> Other than that, all the meaning imparted to @code{FP_REGNUM} is
> imparted by the machine-dependent code.  So, @code{FP_REGNUM} can have
> any value that is convenient for the code that creates new frames.
> (@code{create_new_frame} calls @code{INIT_EXTRA_FRAME_INFO} if it is
> defined; that is where you should use the @code{FP_REGNUM} value, if
> your frames are nonstandard.)
Hmm, I guess this could do with a similar s/FP_REGNUM/read_fp/ 
transformation?

Andrew