From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Alexandre Oliva Cc: gdb-patches@sourceware.cygnus.com Subject: Re: ARM frame fp is not always FP_REGNUM Date: Tue, 04 Jul 2000 01:09:00 -0000 Message-id: <39619B5D.377E1FB2@cygnus.com> References: <39617827.29D15730@cygnus.com> <39619215.E49230D9@cygnus.com> X-SW-Source: 2000-07/msg00034.html Alexandre Oliva wrote: > > On Jul 4, 2000, Andrew Cagney 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 To: GDB Patches 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 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 (gdb) print/a main+4 $3 = 0xffffffffa0020290 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 To: Alexandre Oliva 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: 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 > * 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.