[patch/mips, rfc] Don't define FP_REGNUM

Andrew Cagney ac131313@ges.redhat.com
Tue Sep 17 16:27:00 GMT 2002


> Hello,
> 
> Ok, so this takes things out of the theory stage :-)
> 
> The attached patch eliminates the totally bogus definition of FP_REGNUM from the MIPS target.  It was being mapped to a pseudo register and that pseudo register, through luck, not good management, sometimes contained the contents of the SP.  It now always returns the SP.
> 
> To get this patch working, I needed to modify ``legacy_virtual_frame_pointer'' (used by the tracepoint code) so that it tries FP_REGNUM and then SP_REGNUM as a possible frame pointer register.  As I write:
> 
> -  gdb_assert (FP_REGNUM >= 0);
> -  *frame_regnum = FP_REGNUM;
> +  /* FIXME: cagney/2002-09-13: This code is used when identifying the
> +     frame pointer of the current PC.  It is assuming that a single
> +     register and an offset can determine this.  Instead it should
> +     generate a byte code expression that computes the current FP.  */
> +  if (FP_REGNUM >= 0 && FP_REGNUM < NUM_REGS)
> +    *frame_regnum = FP_REGNUM;
> +  else if (SP_REGNUM >= 0 && SP_REGNUM < NUM_REGS)
> +    *frame_regnum = SP_REGNUM;
> +  else
> +    /* Should this be an internal error?  I guess so, it is reflecting
> +       an architectural limitation in the current design.  */
> +    internal_error (__FILE__, __LINE__, "No virtual frame pointer available");
>    *frame_offset = 0;
> 
> For the MIPS to work, a custom virtual_frame_pointer() function would be needed.  I don't see any point in implementing this, though, as there is no tracepoint target to test it against.  Anyway, coments on this aspect of the patch?    If not, I'll check it in.
> 
> [Hmm, need to mention this in the NEWS file.  The MIPS $fp will finally behave as specified in the documentation.]

I've checked in the attached.  I think the NEWS entry is ok.

Andrew

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diffs
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20020917/d8459c1e/attachment.ksh>


More information about the Gdb-patches mailing list