Re: ARM frame fp is not always FP_REGNUM

Re: ARM frame fp is not always FP_REGNUM

[Andrew Cagney]

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.

What exactly is the behavour you're seeing and what behavour are you
trying to achieve.

	Andrew
From aoliva@redhat.com Mon Jul 03 22:53:00 2000
From: Alexandre Oliva <aoliva@redhat.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: ARM frame fp is not always FP_REGNUM
Date: Mon, 03 Jul 2000 22:53:00 -0000
Message-id: <or1z1afnle.fsf@guarana.lsd.ic.unicamp.br>
References: <orn1jyfpso.fsf@guarana.lsd.ic.unicamp.br> <39617827.29D15730@cygnus.com>
X-SW-Source: 2000-07/msg00021.html
Content-length: 673

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.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: ARM frame fp is not always FP_REGNUM

[Andrew Cagney]

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.

How does this compare to when you do an info registers when at the inner
most frame?

Hmm, I remember reading something about this in the doco recently. 
Check:

http://sourceware.cygnus.com/gdb/onlinedocs/gdb_9.html#SEC60
@value{GDBN} has four ``standard'' register names that are available (in
expressions) on most machines---whenever they do not conflict with an
architecture's canonical mnemonics for registers.  The register names
@code{$pc} and @code{$sp} are used for the program counter register and
the stack pointer.  @code{$fp} is used for a register that contains a
pointer to the current stack frame, and @code{$ps} is used for a
register that contains the processor status.  For example,
you could print the program counter in hex with


This suggests that providing the ``$fp'' pseudo register is wrong for
this target.

	Andrew
From ac131313@cygnus.com Tue Jul 04 00:31:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Alexandre Oliva <aoliva@redhat.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: StrongARM: str stores different PC
Date: Tue, 04 Jul 2000 00:31:00 -0000
Message-id: <39619281.DDECCB6C@cygnus.com>
References: <or3dlqe54f.fsf@guarana.lsd.ic.unicamp.br>
X-SW-Source: 2000-07/msg00031.html
Content-length: 72

Just one BTW, use sim_io_eprintf (....) for the error/warning.

	Andrew
From aoliva@redhat.com Tue Jul 04 00:44:00 2000
From: Alexandre Oliva <aoliva@redhat.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: ARM frame fp is not always FP_REGNUM
Date: Tue, 04 Jul 2000 00:44:00 -0000
Message-id: <oru2e6cpaz.fsf@guarana.lsd.ic.unicamp.br>
References: <orn1jyfpso.fsf@guarana.lsd.ic.unicamp.br> <39617827.29D15730@cygnus.com> <or1z1afnle.fsf@guarana.lsd.ic.unicamp.br> <39619215.E49230D9@cygnus.com>
X-SW-Source: 2000-07/msg00032.html
Content-length: 1173

On Jul  4, 2000, Andrew Cagney <ac131313@cygnus.com> wrote:

> Alexandre Oliva wrote:

>> 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.

> How does this compare to when you do an info registers when at the inner
> most frame?

That's exactly the case.

Given this sample assembly program:

	.global _start
_start:
	mov	r11, #1

After executing the first instruction, GDB will print:

(gdb) info reg
[...]
r11            0x800    2048
r12            0x0      0
sp             0x800    2048
[...]
(gdb) p $fp
$1 = 1

> This suggests that providing the ``$fp'' pseudo register is wrong for
> this target.

Or that, on ARM, $fp should obtain the value of frame->framereg,
instead of FP_REGNUM.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: ARM frame fp is not always FP_REGNUM

[Andrew Cagney]

Alexandre Oliva wrote:
> 
> On Jul  4, 2000, Andrew Cagney <ac131313@cygnus.com> wrote:
> 
> > Alexandre Oliva wrote:
> 
> >> 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.
> 
> > How does this compare to when you do an info registers when at the inner
> > most frame?
> 
> That's exactly the case.
> 
> Given this sample assembly program:
> 
>         .global _start
> _start:
>         mov     r11, #1
> 
> After executing the first instruction, GDB will print:
> 
> (gdb) info reg
> [...]
> r11            0x800    2048
> r12            0x0      0
> sp             0x800    2048
> [...]
> (gdb) p $fp
> $1 = 1
> 
> > This suggests that providing the ``$fp'' pseudo register is wrong for
> > this target.
> 
> Or that, on ARM, $fp should obtain the value of frame->framereg,
> instead of FP_REGNUM.

``Same diff?'' :-)  Hmm, actually, no. The documentation is saying that
when the hardware has a real $fp, $fp always refers to that hardware
register.  That would be returned by:

  get_saved_register (myaddr, &optim, (CORE_ADDR *) NULL, frame,
                      regnum, (enum lval_type *) NULL);

Neither ->framereg nor FP_REGNUM need to even come into the picture.  To
do it, I think you would need to:

	o	redefine FP_REGUM to -1 which
		indicates that it is invalid.

	o	use something else in arm-tdep.c
		I would strongly recommend something
		name space proof like
		enum { ARM_FP_REGNUM = ...};

	o	implement read_fp() and write_fp()

enjoy,
	Andrew
From ac131313@cygnus.com Tue Jul 04 01:42:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: print/a ... (again!)
Date: Tue, 04 Jul 2000 01:42:00 -0000
Message-id: <3961A333.54261AF3@cygnus.com>
X-SW-Source: 2000-07/msg00035.html
Content-length: 1260

Hello,

I'm looking at a 64 bit MIPS debugging a 32 bit ISA (-mips2 -EB) and am
seeing:

  (gdb) p/a main+4
  $1 = 0xa0020290
  (gdb) print main + 4
  $5 = (int (*)()) 0xffffffffa0020290 <main+4>

notice how ``print/a'' doesn't know where main is.  Grubbing around in
printcmd.c I find:

    case 'a':
      {
        /* Truncate address to the size of a target pointer, avoiding
           shifts larger or equal than the width of a CORE_ADDR.  The
           local variable PTR_BIT stops the compiler reporting a shift
           overflow when it won't occure. */
        CORE_ADDR addr = unpack_pointer (type, valaddr);
        int ptr_bit = TARGET_PTR_BIT;
        if (ptr_bit < (sizeof (CORE_ADDR) * HOST_CHAR_BIT))
          addr &= ((CORE_ADDR) 1 << ptr_bit) - 1;
        print_address (addr, stream);
      }
      break;

the problem is that the mask strips off a significant part of the
address.  Commenting out that mask I get the behavour:

  (gdb) print main+4
  $2 = (int (*)()) 0xffffffffa0020290 <main+4>
  (gdb) print/a main+4
  $3 = 0xffffffffa0020290 <main+4>

which is definitly an improvement.  I'm going to have to go diging
around in the e-mail archives.  Anyone care to try to summarize the
rationale behind the mask?

	enjoy,
		Andrew
From rearnsha@arm.com Tue Jul 04 02:19:00 2000
From: Richard Earnshaw <rearnsha@arm.com>
To: Alexandre Oliva <aoliva@redhat.com>
Cc: rearnsha@arm.com
Subject: Re: ARM sim: ldm may switch to/from Thumb mode too 
Date: Tue, 04 Jul 2000 02:19:00 -0000
Message-id: <200007040918.KAA10632@cam-mail2.cambridge.arm.com>
References: <org0pqe6x9.fsf@guarana.lsd.ic.unicamp.br>
X-SW-Source: 2000-07/msg00036.html
Content-length: 384

> I'm checking this in, approved by Nick Clifton:
> 
> 
> Index: sim/arm/ChangeLog
> from  Alexandre Oliva  <aoliva@redhat.com>
> 	* armemu.c (LoadSMult): Use WriteR15() to discard the least
> 	significant bits of PC.

LDM will only do a mode change to/from thumb mode on Architecture 5 or 
later chips.  Architecture 4 chips (ARM7TDMI, ARM9TDMI) must do a mode 
change via bx.

R.

Re: ARM frame fp is not always FP_REGNUM

[Michael Snyder]

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.