Re: ARM frame fp is not always FP_REGNUM

[Michael Snyder <msnyder@cygnus.com>]

Andrew Cagney wrote:
> 
> Alexandre Oliva wrote:
> >
> > read_relative_register_raw_bytes_for_frame() would optimize access to
> > FP_REGNUM by not re-reading it when the value of FP is already known.
> > However, because FP is not always available, sometimes the value of SP
> > is stored in the frame structure as the value of FP.  In this case,
> > reading the value of FP_REGNUM will get you SP instead of the actual
> > value of the FP register.  This patch fixes this bug.  Ok to install?
> 
> I'm not sure about this.
> 
> FP_REGNUM refers to GDB's internal frame-handle / frame-pointer /
> frame-base variable.  It doesn't refer to the ISA register that is seen
> in architectures such as ARM or VAX.  Unfortunatly, some architectures
> have both and this leads to confusion.

Huh???  FP_REGNUM refers to a register.
The "fp" that is displayed by "info registers" sometimes 
refers to gdb's internal pseudo-frame or virtual frame location,
but the constant FP_REGNUM is a real hardware register.

> What exactly is the behavour you're seeing and what behavour are you
> trying to achieve.
> 
>         Andrew
From msnyder@cygnus.com Tue Jul 04 08:57:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Alexandre Oliva <aoliva@redhat.com>
Cc: Andrew Cagney <ac131313@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: ARM frame fp is not always FP_REGNUM
Date: Tue, 04 Jul 2000 08:57:00 -0000
Message-id: <39620927.5D1E@cygnus.com>
References: <orn1jyfpso.fsf@guarana.lsd.ic.unicamp.br> <39617827.29D15730@cygnus.com> <or1z1afnle.fsf@guarana.lsd.ic.unicamp.br>
X-SW-Source: 2000-07/msg00039.html
Content-length: 601

Alexandre Oliva wrote:
> 
> On Jul  4, 2000, Andrew Cagney <ac131313@cygnus.com> wrote:
> 
> > FP_REGNUM refers to GDB's internal frame-handle / frame-pointer /
> > frame-base variable.
> 
> On ARM, it's register 11, which is a real register.  But SP_REGNUM is
> register 13.  Then, when framereg == 13 in EXTRA_FRAME_INFO, `info
> regs' will display the value of r13 for r11, and the actual value of
> r11 cannot be obtained.

Yes it can.  If you say "print $fp" you will get the value
of register 11.  I know this is confusing -- nay, broken.
We've talked for a long time about what to do about it.
From kettenis@wins.uva.nl Tue Jul 04 15:58:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: ac131313@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: [PATCH] TODO update.
Date: Tue, 04 Jul 2000 15:58:00 -0000
Message-id: <200007042258.e64MwK200871@delius.kettenis.local>
X-SW-Source: 2000-07/msg00040.html
Content-length: 953

Andrew,

Prompted by your snippet of the TODO file, I tweaked it somewhat to
reflect reality a bit closer.

Mark

Index: TODO
===================================================================
RCS file: /cvs/src/src/gdb/TODO,v
retrieving revision 1.37
diff -u -p -r1.37 TODO
--- TODO	2000/06/23 08:12:27	1.37
+++ TODO	2000/07/04 22:54:35
@@ -35,11 +35,9 @@ x86 targets.
 x86 linux GDB and SIGALRM (???)
 http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00803.html
 
-I know there are problems with single stepping through signal
-handlers.  These problems were present in 4.18.  They were just masked
-because 4.18 failed to recognize signal handlers.  Fixing it is not
-easy, and will require changes to handle_inferior_event(), that I
-prefer not to make before the 5.0 release.
+This problem has been fixed, but a regression test still needs to be
+added to the testsuite:
+ http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00309.html
 
 Mark
 
From ac131313@cygnus.com Tue Jul 04 19:11:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: msnyder@cygnus.com
Cc: Alexandre Oliva <aoliva@redhat.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: ARM frame fp is not always FP_REGNUM
Date: Tue, 04 Jul 2000 19:11:00 -0000
Message-id: <396298DC.4543E9BF@cygnus.com>
References: <orn1jyfpso.fsf@guarana.lsd.ic.unicamp.br> <39617827.29D15730@cygnus.com> <396208DF.76CA@cygnus.com>
X-SW-Source: 2000-07/msg00041.html
Content-length: 1919

Michael Snyder wrote:
> 
> Andrew Cagney wrote:
> >
> > Alexandre Oliva wrote:
> > >
> > > read_relative_register_raw_bytes_for_frame() would optimize access to
> > > FP_REGNUM by not re-reading it when the value of FP is already known.
> > > However, because FP is not always available, sometimes the value of SP
> > > is stored in the frame structure as the value of FP.  In this case,
> > > reading the value of FP_REGNUM will get you SP instead of the actual
> > > value of the FP register.  This patch fixes this bug.  Ok to install?
> >
> > I'm not sure about this.
> >
> > FP_REGNUM refers to GDB's internal frame-handle / frame-pointer /
> > frame-base variable.  It doesn't refer to the ISA register that is seen
> > in architectures such as ARM or VAX.  Unfortunatly, some architectures
> > have both and this leads to confusion.
> 
> Huh???  FP_REGNUM refers to a register.
> The "fp" that is displayed by "info registers" sometimes
> refers to gdb's internal pseudo-frame or virtual frame location,
> but the constant FP_REGNUM is a real hardware register.

I read it as the hardware or pseudo register that directly corresponds
to GDB's ``$fp'' pseudo register.  parse.c:build_parse() maps $fp ->
FP_REGNUM.  (mental note, fix buffer overrun in build_parse()).  Some
targets have a real $fp (ARM, VAX) so the obvious thing to do was to map
FP_REGNUM onto the real register.  Other targets don't have a real $fp
so it is mapped onto a pseudo register (MIPS).

As Alexandre pointed out, things relied on pseudo-$fp <-> FP_REGNUM <->
frame->frame <-> hardware-$fp but in modern times, with frameless
functions, this makes little sense.

My reading of the doco is that, when the target has a true hardware $fp,
then the pseudo $fp register shouldn't be provided.  Per other e-mail, I
think this can be implemented by invalidating FP_REGNUM (set it to -1)
and instead provide read_fp() and write_fp().

	Andrew
From ac131313@cygnus.com Wed Jul 05 01:01:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Delete sim/SIM_HAVE_BREAKPOINTS and gdb/SIM_HAS_BREAKPOINTS
Date: Wed, 05 Jul 2000 01:01:00 -0000
Message-id: <3962EB23.D6E08550@cygnus.com>
X-SW-Source: 2000-07/msg00042.html
Content-length: 1262

Hello,

One of the target macros that keeps lurking in GDB is
SIM_HAS_BREAKPOINTS.  Checking the actual code, I've found that only the
d30v actually uses it.  (The d30v is a VLIW embedded processor).  Given
that the functionality provided by SIM_HAS_BREAKPOINTS can be
implemented using other more direct means I'd like to propose that the
macro be purged.

The idea behind the code (and sounds good in theory) was that the
simulator should administer its breakpoints directly. Unfortunatly,
reality got in the way, and several things conspired to ensure that it
was never widely adopted.  Of note are:

	o	as I mentioned, only one
		target adopted it in the end.

		Several other sim targets think
		that they are using the mechanism
		but a more careful examination of
		the source code reveals otherwize :-)

	o	turns out that equivalent
		functionality can be achieved
		by having GDB pass signals
		back to the simulator when
		an unknown breakpoint is
		encountered.

		It also turns out that providing
		this functionality is far more
		useful.

	o	It used the s/w breakpoint
		mechanism, just like GDB.

		If it had exploited the
		sim/common h/w breakpoint
		and watchpoint framework
		then I suspect it would
		be heavily used.

Any comments?

	Andrew
From ac131313@cygnus.com Wed Jul 05 01:14:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Bill Nottingham <notting@redhat.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Makefile.in: fix install-info
Date: Wed, 05 Jul 2000 01:14:00 -0000
Message-id: <3962EE1D.DDC6A3AE@cygnus.com>
References: <20000613001035.B4580@nostromo.devel.redhat.com>
X-SW-Source: 2000-07/msg00043.html
Content-length: 1122

Bill Nottingham wrote:
> 
> This patch fixes 'make install-info' so that
> 
> ./configure --infodir=/usr/share/info
> make install-info infodir=/somewhere/else/usr/share/info
> 
> works correctly. Is this the correct place to fix this, or
> does this need changed somewhere else?

For the way GDB is currently set up, it (I believe) is correct. 
automake does it very differently but we're not using automake.

I've applied/tested the change.

	Thanks!
		Andrew

> 2000-06-12  Bill Nottingham  <notting@redhat.com>
> 
>         * Makefile.in: add $(infodir) to FLAGS_TO_PASS
> 
>  Index: Makefile.in
> ===================================================================
> RCS file: /cvs/src/src/gdb/Makefile.in,v
> retrieving revision 1.35
> diff -u -p -r1.35 Makefile.in
> --- Makefile.in 2000/06/12 06:09:04     1.35
> +++ Makefile.in 2000/06/13 04:01:17
> @@ -368,6 +368,7 @@ ANNOTATE_OBS = annotate.o
>  FLAGS_TO_PASS = \
>         "prefix=$(prefix)" \
>         "exec_prefix=$(exec_prefix)" \
> +       "infodir=$(infodir)" \
>         "against=$(against)" \
>         "AR=$(AR)" \
>         "AR_FLAGS=$(AR_FLAGS)" \
From ac131313@cygnus.com Wed Jul 05 01:29:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [patch] Set SER_HARDWIRE using autoconf
Date: Wed, 05 Jul 2000 01:29:00 -0000
Message-id: <3962F1B8.325BE74@cygnus.com>
References: <39447FB9.DD0ED9BE@cygnus.com> <200006180452.AAA01630@indy.delorie.com>
X-SW-Source: 2000-07/msg00044.html
Content-length: 1635

Eli Zaretskii wrote:
> 
> > Date: Mon, 12 Jun 2000 16:14:17 +1000
> > From: Andrew Cagney <ac131313@cygnus.com>
> >
> > I've checked in the attached.  By default a target will be built with
> > ser-tcp.o.  go32*-*-* is currently the only exception.
> 
> Andrew,
> 
> I didn't have time to actually test this change, but I think this is
> wrong: the DJGPP port uses "i386-pc-msdosdjgpp" as the value of $host.
> The value if ${gdb_host} is set to "go32", but I don't think you are
> referencing that variable in configure.in (reproduced below), are you?
> 
> I think to get this right, you need to allow both go32*-*-* and
> *-*-*djgpp in ${host}.

Up, yes. Does:

  case ${host} in
    *go32* ) SER_HARDWIRE=ser-go32.o ;;
    *djgpp* ) SER_HARDWIRE= ;;
  esac

look safer?

	Andrew


> > Index: configure.in
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/configure.in,v
> > retrieving revision 1.36
> > diff -p -r1.36 configure.in
> > *** configure.in      2000/06/11 01:39:08     1.36
> > --- configure.in      2000/06/12 06:04:04
> > *************** AC_CACHE_CHECK([for cygwin], gdb_cv_os_c
> > *** 626,631 ****
> > --- 626,640 ----
> >   lose
> >   #endif],[gdb_cv_os_cygwin=yes],[gdb_cv_os_cygwin=no])])
> >
> > +
> > + dnl Figure out which of the many generic ser-*.c files the _host_ supports.
> > + SER_HARDWIRE="ser-unix.o ser-pipe.o ser-tcp.o"
> > + case ${host} in
> > +   go32*-*-* ) SER_HARDWIRE=ser-go32.o ;;
> > + esac
> > + AC_SUBST(SER_HARDWIRE)
> > +
> > +
> >   dnl Figure out which term library to use.
> >   if test x$gdb_host = xgo32; then
> >     TERM_LIB=
From ac131313@cygnus.com Wed Jul 05 01:48:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: BINUTILS Patches <binutils@sourceware.cygnus.com>, GDB Patches <gdb-patches@sourceware.cygnus.com>
Cc: Andreas Jaeger <aj@suse.de>
Subject: Re: Update config.guess, config.sub, texinfo.tex
Date: Wed, 05 Jul 2000 01:48:00 -0000
Message-id: <3962F60E.E492A153@cygnus.com>
References: <3931F0DF.868A3085@cygnus.com> <3934E6D5.C2AEB97@cygnus.com> <u8wvkbgf3t.fsf@gromit.rhein-neckar.de>
X-SW-Source: 2000-07/msg00045.html
Content-length: 5720

Andreas Jaeger wrote:
> 
> >>>>> Andrew Cagney writes:
> 
> Andrew> Andrew Cagney wrote:
> >>
> >> FYI,
> >>
> >> I intend updating these with more recent copies from the official
> >> releases.  For texinfo.tex that would be makeinfo-4.0.
> 
> Andrew> The texinfo.tex file is now in.
> 
> The most recent version of texinfo.tex is on ftp.gnu.org as a single
> file.
> ls -l manual/texinfo.tex
> -rw-r--r--   1 aj       users      200234 May 17 09:58 manual/texinfo.tex
> 
> It contains:
> \def\texinfoversion{2000-05-16.11}
> 
> I advise to use that version instead,
> Andreas

(I've just got back to this) I intend bringing in:

\def\texinfoversion{2000-05-28.15}

obtained from ftp://ftp.gnu.org/gnu/texinfo.tex (I couldn't find the
file manual/texinfo.tex :-)  The differences between it and the current
texinfo.tex (from makeinfo 4.0) are attatched.

Any problems?

	Andrew
? diffs
Index: texinfo.tex
===================================================================
RCS file: /cvs/src/src/texinfo/texinfo.tex,v
retrieving revision 1.2
diff -p -r1.2 texinfo.tex
*** texinfo.tex	2000/05/31 10:18:58	1.2
--- texinfo.tex	2000/07/05 08:41:43
***************
*** 3,9 ****
  % Load plain if necessary, i.e., if running under initex.
  \expandafter\ifx\csname fmtname\endcsname\relax\input plain\fi
  %
! \def\texinfoversion{1999-09-25.10}
  %
  % Copyright (C) 1985, 86, 88, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99
  % Free Software Foundation, Inc.
--- 3,9 ----
  % Load plain if necessary, i.e., if running under initex.
  \expandafter\ifx\csname fmtname\endcsname\relax\input plain\fi
  %
! \def\texinfoversion{2000-05-28.15}
  %
  % Copyright (C) 1985, 86, 88, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99
  % Free Software Foundation, Inc.
***************
*** 214,219 ****
--- 214,222 ----
      \normalturnoffactive  % \ in index entries must not stay \, e.g., if
                     % the page break happens to be in the middle of an example.
      \shipout\vbox{%
+       % Do this early so pdf references go to the beginning of the page.
+       \ifpdfmakepagedest \pdfmkdest{\the\pageno} \fi
+       %
        \ifcropmarks \vbox to \outervsize\bgroup
          \hsize = \outerhsize
          \vskip-\topandbottommargin
***************
*** 243,250 ****
          \unvbox\footlinebox
        \fi
        %
-       \ifpdfmakepagedest \pdfmkdest{\the\pageno} \fi
-       %
        \ifcropmarks
            \egroup % end of \vbox\bgroup
          \hfil\egroup % end of (centering) \line\bgroup
--- 246,251 ----
*************** where each line of input produces a line
*** 891,897 ****
      \fi}
    \def\pdfmkdest#1{\pdfdest name{#1@} xyz}
    \def\pdfmkpgn#1{#1@}
!   \let\linkcolor = \Cyan
    \def\endlink{\Black\pdfendlink}
    % Adding outlines to PDF; macros for calculating structure of outlines
    % come from Petr Olsak
--- 892,898 ----
      \fi}
    \def\pdfmkdest#1{\pdfdest name{#1@} xyz}
    \def\pdfmkpgn#1{#1@}
!   \let\linkcolor = \Blue  % was Cyan, but that seems light?
    \def\endlink{\Black\pdfendlink}
    % Adding outlines to PDF; macros for calculating structure of outlines
    % come from Petr Olsak
*************** where each line of input produces a line
*** 906,912 ****
        \closein 1 
        \indexnofonts
        \def\tt{}
!       % thanh's hack / proper braces in bookmarks  
        \edef\mylbrace{\iftrue \string{\else}\fi}\let\{=\mylbrace
        \edef\myrbrace{\iffalse{\else\string}\fi}\let\}=\myrbrace
        %
--- 907,914 ----
        \closein 1 
        \indexnofonts
        \def\tt{}
!       \let\_ = \normalunderscore
!       % Thanh's hack / proper braces in bookmarks  
        \edef\mylbrace{\iftrue \string{\else}\fi}\let\{=\mylbrace
        \edef\myrbrace{\iffalse{\else\string}\fi}\let\}=\myrbrace
        %
*************** where each line of input produces a line
*** 1670,1676 ****
  }
  
  % Subroutines used in generating headings
! % Produces Day Month Year style of output.
  \def\today{%
    \number\day\space
    \ifcase\month
--- 1672,1681 ----
  }
  
  % Subroutines used in generating headings
! % This produces Day Month Year style of output.
! % Only define if not already defined, in case a txi-??.tex file has set
! % up a different format (e.g., txi-cs.tex does this).
! \ifx\today\undefined
  \def\today{%
    \number\day\space
    \ifcase\month
*************** where each line of input produces a line
*** 1679,1684 ****
--- 1684,1690 ----
    \or\putwordMSep\or\putwordMOct\or\putwordMNov\or\putwordMDec
    \fi
    \space\number\year}
+ \fi
  
  % @settitle line...  specifies the title of the document, for headings.
  % It generates no output of its own.
*************** width0pt\relax} \fi
*** 4710,4716 ****
  \def\deftypeivarheader#1#2#3{%
    \dosubind{vr}{\code{#3}}{\putwordof\ \code{#1}}% entry in variable index
    \begingroup
!     \defname{#3}{\putwordInstanceVariableof\ \code{#1}}%
      \defvarargs{#3}%
    \endgroup
  }
--- 4716,4723 ----
  \def\deftypeivarheader#1#2#3{%
    \dosubind{vr}{\code{#3}}{\putwordof\ \code{#1}}% entry in variable index
    \begingroup
!     \defname{\defheaderxcond#2\relax$$$#3}
!             {\putwordInstanceVariableof\ \code{#1}}%
      \defvarargs{#3}%
    \endgroup
  }
*************** should work if nowhere else does.}
*** 5794,5800 ****
  % Use @afourwide to print on European A4 paper in wide format.
  \def\afourwide{%
    \afourpaper
!   \internalpagesizes{9.5in}{6.5in}{\hoffset}{\normaloffset}{\bindingoffset}{7mm}%
    %
    \globaldefs = 0
  }
--- 5801,5807 ----
  % Use @afourwide to print on European A4 paper in wide format.
  \def\afourwide{%
    \afourpaper
!   \internalpagesizes{6.5in}{9.5in}{\hoffset}{\normaloffset}{\bindingoffset}{7mm}%
    %
    \globaldefs = 0
  }
From rearnsha@arm.com Wed Jul 05 02:37:00 2000
From: Richard Earnshaw <rearnsha@arm.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: rearnsha@arm.com
Subject: Re: ARM frame fp is not always FP_REGNUM 
Date: Wed, 05 Jul 2000 02:37:00 -0000
Message-id: <200007050936.KAA06640@cam-mail2.cambridge.arm.com>
References: <396298DC.4543E9BF@cygnus.com>
X-SW-Source: 2000-07/msg00046.html
Content-length: 1260

> > 
> > Huh???  FP_REGNUM refers to a register.
> > The "fp" that is displayed by "info registers" sometimes
> > refers to gdb's internal pseudo-frame or virtual frame location,
> > but the constant FP_REGNUM is a real hardware register.
> 
> I read it as the hardware or pseudo register that directly corresponds
> to GDB's ``$fp'' pseudo register.  parse.c:build_parse() maps $fp ->
> FP_REGNUM.  (mental note, fix buffer overrun in build_parse()).  Some
> targets have a real $fp (ARM, VAX) so the obvious thing to do was to map
> FP_REGNUM onto the real register.  Other targets don't have a real $fp
> so it is mapped onto a pseudo register (MIPS).
> 
> As Alexandre pointed out, things relied on pseudo-$fp <-> FP_REGNUM <->
> frame->frame <-> hardware-$fp but in modern times, with frameless
> functions, this makes little sense.
> 
> My reading of the doco is that, when the target has a true hardware $fp,
> then the pseudo $fp register shouldn't be provided.  Per other e-mail, I
> think this can be implemented by invalidating FP_REGNUM (set it to -1)
> and instead provide read_fp() and write_fp().

On ARM, FP is a well-known alias for R11.  Giving the value of any 
register other than r11 if the user types $fp would be *very* misleading.

R.