[PATCH/ARM] Fix support of longjmp for ARM Linux.

[PATCH/ARM] Fix support of longjmp for ARM Linux.

[Matthew Gretton-Dann]

[-- Attachment #1: Type: text/plain, Size: 821 bytes --]

Hi,

Can someone please review and comment on the attached patch?

The patch fixes support for longjmp on ARM Linux.  Dependent on the FP
model in use the location of the PC to use as the long jump return value
is stored in different locations in the long jump buffer.  Currently gdb
uses a hard-coded value which works for only one FP model, this patch
corrects this.

A suggested ChangeLog is:

2010-04-29  Matthew Gretton-Dann  <matthew.gretton-dann@arm.com>

	* arm-linux-tdep.c (ARM_LINUX_JB_PC): Remove.
	(ARM_LINUX_JB_PC_FPA): Add, offset of PC in longjmp buffer for 
	FPA.
	(ARM_LINUX_JP_PC_EABI): Add, offset of PC in longjmp buffer for 
	EABI.
	(arm_linux_init_abi): Set up JB_PC field dependent on FP model 
	in use.

Thanks,

Matt

-- 
Matthew Gretton-Dann
Principal Engineer - Tools, PD Software
ARM Limited

[-- Attachment #2: 1004-gdb-longjmp.patch --]
[-- Type: text/x-patch, Size: 1991 bytes --]

Index: gdb/arm-linux-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/arm-linux-tdep.c,v
retrieving revision 1.74
diff -u -p -u -p -r1.74 arm-linux-tdep.c
--- gdb/arm-linux-tdep.c	1 Feb 2010 16:13:15 -0000	1.74
+++ gdb/arm-linux-tdep.c	29 Apr 2010 12:49:15 -0000
@@ -82,9 +82,20 @@ static const char arm_linux_thumb2_be_br
 
 static const char arm_linux_thumb2_le_breakpoint[] = { 0xf0, 0xf7, 0x00, 0xa0 };
 
-/* Description of the longjmp buffer.  */
+/* Description of the longjmp buffer.  The buffer is treated as an array of 
+   elements of size ARM_LINUX_JB_ELEMENT_SIZE.
+
+   The location of saved registers in this buffer (in particular the PC
+   to use after longjmp is called) varies depending on the ABI (in 
+   particular the FP model) and also (possibly) the C Library.
+
+   For glibc, eglibc, and uclibc the following holds:  If the FP model is 
+   SoftVFP or VFP (which implies EABI) then the PC is at offset 9 in the 
+   buffer.  This is also true for the SoftFPA model.  However, for the FPA 
+   model the PC is at offset 21 in the buffer.  */
 #define ARM_LINUX_JB_ELEMENT_SIZE	INT_REGISTER_SIZE
-#define ARM_LINUX_JB_PC			21
+#define ARM_LINUX_JB_PC_FPA		21
+#define ARM_LINUX_JB_PC_EABI		9
 
 /*
    Dynamic Linking on ARM GNU/Linux
@@ -877,7 +888,22 @@ arm_linux_init_abi (struct gdbarch_info 
   if (tdep->fp_model == ARM_FLOAT_AUTO)
     tdep->fp_model = ARM_FLOAT_FPA;
 
-  tdep->jb_pc = ARM_LINUX_JB_PC;
+  switch (tdep->fp_model)
+    {
+    case ARM_FLOAT_FPA:
+      tdep->jb_pc = ARM_LINUX_JB_PC_FPA;
+      break;
+    case ARM_FLOAT_SOFT_FPA:
+    case ARM_FLOAT_SOFT_VFP:
+    case ARM_FLOAT_VFP:
+      tdep->jb_pc = ARM_LINUX_JB_PC_EABI;
+      break;
+    default:
+      internal_error
+	(__FILE__, __LINE__,
+         _("arm_linux_init_abi: Floating point model not supported"));
+      break;
+    }
   tdep->jb_elt_size = ARM_LINUX_JB_ELEMENT_SIZE;
 
   set_solib_svr4_fetch_link_map_offsets

Re: [PATCH/ARM] Fix support of longjmp for ARM Linux.

[Richard Earnshaw]

On Thu, 2010-04-29 at 14:31 +0100, Matthew Gretton-Dann wrote:
> Hi,
> 
> Can someone please review and comment on the attached patch?
> 
> The patch fixes support for longjmp on ARM Linux.  Dependent on the FP
> model in use the location of the PC to use as the long jump return value
> is stored in different locations in the long jump buffer.  Currently gdb
> uses a hard-coded value which works for only one FP model, this patch
> corrects this.
> 
> A suggested ChangeLog is:
> 
> 2010-04-29  Matthew Gretton-Dann  <matthew.gretton-dann@arm.com>
> 
> 	* arm-linux-tdep.c (ARM_LINUX_JB_PC): Remove.
> 	(ARM_LINUX_JB_PC_FPA): Add, offset of PC in longjmp buffer for 
> 	FPA.
> 	(ARM_LINUX_JP_PC_EABI): Add, offset of PC in longjmp buffer for 
> 	EABI.
> 	(arm_linux_init_abi): Set up JB_PC field dependent on FP model 
> 	in use.
> 
> Thanks,
> 
> Matt


This is ok.

Danniel, can we give Matt write-after a commit bit, please.  He's
already got an account for binutils work.

R.

Re: [PATCH/ARM] Fix support of longjmp for ARM Linux.

[Joel Brobecker]

> Daniel, can we give Matt write-after a commit bit, please.  He's
> already got an account for binutils work.

No problem. Since he's already setup for binutils, he's also setup
for GDB.

Matt,

can you commit a patch in GDB that adds yourself to the gdb/MAINTAINERS
in the Write After Approval category? Please treat this as any other patch,
which means adding a ChangeLog entry and sending the patch to this list.
Once this is done, you should also be setup to commit your patch for arm.

-- 
Joel

Re: [PATCH/ARM] Fix support of longjmp for ARM Linux.

[Matthew Gretton-Dann]

On Thu, 2010-04-29 at 07:35 -0700, Joel Brobecker wrote:
> > Daniel, can we give Matt write-after a commit bit, please.  He's
> > already got an account for binutils work.
> 
> No problem. Since he's already setup for binutils, he's also setup
> for GDB.
> 
> Matt,
> 
> can you commit a patch in GDB that adds yourself to the gdb/MAINTAINERS
> in the Write After Approval category? Please treat this as any other patch,
> which means adding a ChangeLog entry and sending the patch to this list.
> Once this is done, you should also be setup to commit your patch for arm.

Both of these have now been committed.

Thanks,

Matt

-- 
Matthew Gretton-Dann
Prinicipal Engineer - Tools, PD Software
ARM Limited

Re: [PATCH/ARM] Fix support of longjmp for ARM Linux.

[Daniel Jacobowitz]

On Thu, Apr 29, 2010 at 02:49:43PM +0100, Richard Earnshaw wrote:
> 
> On Thu, 2010-04-29 at 14:31 +0100, Matthew Gretton-Dann wrote:
> > Hi,
> > 
> > Can someone please review and comment on the attached patch?
> > 
> > The patch fixes support for longjmp on ARM Linux.  Dependent on the FP
> > model in use the location of the PC to use as the long jump return value
> > is stored in different locations in the long jump buffer.  Currently gdb
> > uses a hard-coded value which works for only one FP model, this patch
> > corrects this.

I'm not going to make a fuss, but for the record I am very weakly
opposed to this patch.  The offset of PC in the longjmp buffer is
deliberately left implementation-private by the EABI.  I'd rather we
got back to the generic (step-based or breakpoint-based rather than
jmp_buf-decoding-based) solution to longjmp.exp failures.

On the other hand, I can't see why this should hurt :-)

-- 
Daniel Jacobowitz
CodeSourcery