This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fix PR debug/24444: incorrect frame base in IA64 prologues


On Feb  5, 2006, Daniel Jacobowitz <drow@false.org> wrote:

> Just a general note: once a platform has defined the CFA with or
> without a particular bias to the caller's SP, you can't change it.
> It's an ABI break of a peculiar sort for debuggers.

This would be true if the CFA was actually defined anywhere in debug
info.  On IA64, it isn't, because IA64 doesn't emit call frame
information.  IA64 unwind info is used for stack unwinding, and that
doesn't talk about CFA, and has everything relative to actual values
in registers, rather than some virtual abstract entity.  IA64 debug
info now uses the CFA as DW_AT_frame_base, but frame_base is arbitrary
anyway, so it can be changed at will.

> It looks to me like ia64-tdep.c does know about the magic +16, but
> I'm not familiar enough with ia64 to work that out for sure.

It does mention the 16 constant, indeed, but that's just where it
skips the red zone for passing out arguments in inferior calls, and
where it computes `cache->base' for a sigtramp frame.  It's adding 16
because that's the hardcoded frame size mentioned in the comment above
that statement; it knows the frame pointer is 16 bytes above the stack
pointer, and that's just that.

I claim it can't possibly be making any assumptions about the CFA
because there is no CFA-relative information anywhere for it to use;
everything is relative.  This is probably why the IA64 docs I've seen
refrain from defining CFA: it is simply not necessary, and it is not
part of the ABI because it just isn't anywhere to be used.

Of course this poses a problem should we start using
DW_OP_call_frame_cfa in debug info, because then we'd have to have a
common definition of CFA that every user agrees with, and if ours
disagree, we might have to undergo an ABI break if we've already
started using an incompatible definition.

That said, if anyone feels we should back out the change, here's one
that will bring us back to the SP+16 definition of CFA that we used
before, and adjust the value used to set the CFA location at function
entry points to match.  I haven't tested it at all, and I don't think
it's the right way to go, but I thought I'd post right away, while
this stuff is still hot in my personal cache :-)

Index: gcc/config/ia64/unwind-ia64.c
===================================================================
--- gcc/config/ia64/unwind-ia64.c	(revision 110597)
+++ gcc/config/ia64/unwind-ia64.c	(working copy)
@@ -2067,7 +2067,7 @@
 }
 
 /* Fill in CONTEXT for top-of-stack.  The only valid registers at this
-   level will be the return address and the CFA.  */
+   level will be the return address and the CFA.  Note that CFA = SP+16.  */
    
 #define uw_init_context(CONTEXT)					\
   do {									\
@@ -2083,7 +2083,7 @@
 {
   void *rp = __builtin_extract_return_addr (__builtin_return_address (0));
   /* Set psp to the caller's stack pointer.  */
-  void *psp = __builtin_dwarf_cfa ();
+  void *psp = __builtin_dwarf_cfa () - 16;
   _Unwind_FrameState fs;
   unsigned long rnat, tmp1, tmp2;
 
Index: gcc/config/ia64/ia64.h
===================================================================
--- gcc/config/ia64/ia64.h	(revision 110597)
+++ gcc/config/ia64/ia64.h	(working copy)
@@ -981,11 +981,9 @@
    On some machines it may depend on the data type of the function.  */
 #define FIRST_PARM_OFFSET(FUNDECL) 0
 
-/* The CFA is defined as the SP at the call site, so we have to take
-   into account that the first argument pointer is
-   STACK_POINTER_OFFSET bytes off the stack pointer.  */
-#define ARG_POINTER_CFA_OFFSET(FNDECL) \
-  (FIRST_PARM_OFFSET (FNDECL) - STACK_POINTER_OFFSET)
+/* The CFA is past the red zone, not at the entry-point stack
+   pointer.  */
+#define INCOMING_FRAME_SP_OFFSET STACK_POINTER_OFFSET
 
 /* A C expression whose value is RTL representing the value of the return
    address for the frame COUNT steps up from the current frame, after the
-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Secretary for FSF Latin America        http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]