[rfa/doco] FRAME_FP -> read_fp
Andrew Cagney
ac131313@redhat.com
Wed Nov 20 08:26:00 GMT 2002
> 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
More information about the Gdb-patches
mailing list