ARM backtrace() adjustment

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

ARM backtrace() adjustment

Daniel Jacobowitz-2
Mark Shinwell (and others here, but he did the heavy lifting) tracked
down why backtrace() was stopping in our ARM NPTL builds without
returning any frames.  The current stack frame was not offset,
but the first stack frame was, so it appeared we'd wandered off into
the woods.

This improves the situation - at least, if you're using gcc 3.x, or
Mark's patch just approved for 4.2.  In the future, we're going to need
to come up with some other way to do this, at least for EABI targets.

--
Daniel Jacobowitz
CodeSourcery

2006-06-08  Mark Shinwell  <[hidden email]>

        * sysdeps/arm/nptl/pthreaddef.h (CURRENT_STACK_FRAME): Add -12.

Index: sysdeps/arm/nptl/pthreaddef.h
===================================================================
RCS file: /cvs/glibc/ports/sysdeps/arm/nptl/pthreaddef.h,v
retrieving revision 1.1
diff -u -p -r1.1 pthreaddef.h
--- sysdeps/arm/nptl/pthreaddef.h 16 Nov 2005 19:03:42 -0000 1.1
+++ sysdeps/arm/nptl/pthreaddef.h 8 Jun 2006 17:38:03 -0000
@@ -30,8 +30,16 @@
 #define TCB_ALIGNMENT 16
 
 
-/* Location of current stack frame.  */
-#define CURRENT_STACK_FRAME __builtin_frame_address (0)
+/* Location of current stack frame.
+
+   __builtin_frame_address (0) returns the value of the hard frame
+   pointer, which will point at the location of the saved PC on the
+   stack.  Below this in memory is the remainder of the linkage info,
+   occupying 12 bytes.  Therefore in order to address from
+   CURRENT_STACK_FRAME using "struct layout", we need to have the macro
+   return the hard FP minus 12.  Of course, this makes no sense
+   without the obsolete APCS stack layout...  */
+#define CURRENT_STACK_FRAME (__builtin_frame_address (0) - 12)
 
 
 /* XXX Until we have a better place keep the definitions here.  */
Reply | Threaded
Open this post in threaded view
|

Re: ARM backtrace() adjustment

Ladislav Michl-3
On Thu, Jun 08, 2006 at 01:41:11PM -0400, Daniel Jacobowitz wrote:
> Mark Shinwell (and others here, but he did the heavy lifting) tracked
> down why backtrace() was stopping in our ARM NPTL builds without
> returning any frames.  The current stack frame was not offset,
> but the first stack frame was, so it appeared we'd wandered off into
> the woods.
>
> This improves the situation - at least, if you're using gcc 3.x, or
> Mark's patch just approved for 4.2.  In the future, we're going to need
> to come up with some other way to do this, at least for EABI targets.

Hi Daniel,

do you mean this Mark's patch for 4.2?
http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00357.html

I used it for gcc-4.1.1 and it still doesn't work. What is recommended
solution for gcc-4.1.1 users?

Thanks,
        ladis
Reply | Threaded
Open this post in threaded view
|

Re: ARM backtrace() adjustment

Ladislav Michl-3
On Thu, Jun 29, 2006 at 01:08:41PM +0200, Ladislav Michl wrote:
> do you mean this Mark's patch for 4.2?
> http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00357.html
>
> I used it for gcc-4.1.1 and it still doesn't work. What is recommended
> solution for gcc-4.1.1 users?

Well, this is just another example of 'check twice before posting'. Due
to clock skew on nfs server newly built glibc wasn't copied into
target's nfsroot... Works nicely now, thanks to everyone who made it
possible. Just for completeness here is rediffed patch against gcc-4.1.1

--- gcc-4.1.1/gcc/builtins.c.orig 2006-05-08 08:13:23.000000000 +0200
+++ gcc-4.1.1/gcc/builtins.c 2006-06-29 14:35:34.000000000 +0200
@@ -510,12 +510,16 @@
 #else
   rtx tem;
 
-  /* For a zero count, we don't care what frame address we return, so frame
-     pointer elimination is OK, and using the soft frame pointer is OK.
-     For a non-zero count, we require a stable offset from the current frame
-     pointer to the previous one, so we must use the hard frame pointer, and
+  /* For a zero count with __builtin_return_address, we don't care what
+     frame address we return, because target-specific definitions will
+     override us.  Therefore frame pointer elimination is OK, and using
+     the soft frame pointer is OK.
+
+     For a non-zero count, or a zero count with __builtin_frame_address,
+     we require a stable offset from the current frame pointer to the
+     previous one, so we must use the hard frame pointer, and
      we must disable frame pointer elimination.  */
-  if (count == 0)
+  if (count == 0 && fndecl_code == BUILT_IN_RETURN_ADDRESS)
     tem = frame_pointer_rtx;
   else
     {


Best regards,
        ladis