Re: ARM frame fp is not always FP_REGNUM

[Andrew Cagney <ac131313@cygnus.com>]

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.