RFA: try to ensure abort has valid return address

RFA: try to ensure abort has valid return address

[Jim Blandy]

2002-01-12  Jim Blandy  <jimb@redhat.com>

	* gdb.base/coremaker.c (func2): Try to arrange for the return
	address passed to `abort' to fall within `func2', so we can get
	backtraces.

Index: gdb/testsuite/gdb.base/coremaker.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/testsuite/gdb.base/coremaker.c,v
retrieving revision 1.4
diff -c -r1.4 coremaker.c
*** gdb/testsuite/gdb.base/coremaker.c	1999/06/25 23:44:28	1.4
--- gdb/testsuite/gdb.base/coremaker.c	2002/01/12 06:42:09
***************
*** 81,87 ****
  }
  
  void
! func2 ()
  {
    int coremaker_local[5];
    int i;
--- 81,87 ----
  }
  
  void
! func2 (int please_abort)
  {
    int coremaker_local[5];
    int i;
***************
*** 104,116 ****
    for (i = 0; i < 5; i++)
      coremaker_bss += coremaker_local[i];
    coremaker_data = coremaker_ro + 1;
!   abort ();
  }
  
  void
  func1 ()
  {
!   func2 ();
  }
  
  int main ()
--- 104,138 ----
    for (i = 0; i < 5; i++)
      coremaker_bss += coremaker_local[i];
    coremaker_data = coremaker_ro + 1;
! 
!   /* This function used to simply call `abort' unconditionally.
!      However, because GCC sometimes knows that `abort' will never
!      return, the `call' instruction that invokes `abort' would
!      sometimes be the very last instruction in this function.  The
!      epilogue instructions you'd normally expect --- deallocating the
!      frame, jumping to the return address --- were omitted, since
!      they'd never be reached anyway.  This means that the return
!      address passed to abort (which it'll never use) actually points
!      beyond the end of the caller!  Sometimes the return address
!      seemed to be in the next function; sometimes it seemed to be in
!      padding instructions between functions, for which there was no
!      line number info.  In any case, GDB had difficulties producing a
!      backtrace in this case.
! 
!      There's no way to force the compiler not to put the call to
!      `abort' at the very end of the function --- after all, it is
!      functionally correct to do so.  But we hope that putting it in a
!      conditional will make it more likely that GDB can get a
!      backtrace, and find coremaker_local, which is what we really care
!      about.  */
!   if (please_abort)
!     abort ();
  }
  
  void
  func1 ()
  {
!   func2 (1);
  }
  
  int main ()

Re: RFA: try to ensure abort has valid return address

[Andrew Cagney]

> 2002-01-12  Jim Blandy  <jimb@redhat.com>
> 
> * gdb.base/coremaker.c (func2): Try to arrange for the return
> 	address passed to `abort' to fall within `func2', so we can get
> 	backtraces.
> 
> Index: gdb/testsuite/gdb.base/coremaker.c
> ===================================================================
> RCS file: /cvs/cvsfiles/devo/gdb/testsuite/gdb.base/coremaker.c,v
> retrieving revision 1.4
> diff -c -r1.4 coremaker.c
> *** gdb/testsuite/gdb.base/coremaker.c	1999/06/25 23:44:28	1.4
> --- gdb/testsuite/gdb.base/coremaker.c	2002/01/12 06:42:09
> ***************
> *** 81,87 ****
>   }
>   
>   void
> ! func2 ()
>   {
>     int coremaker_local[5];
>     int i;
> --- 81,87 ----
>   }
>   
>   void
> ! func2 (int please_abort)
>   {
>     int coremaker_local[5];
>     int i;
> ***************
> *** 104,116 ****
>     for (i = 0; i < 5; i++)
>       coremaker_bss += coremaker_local[i];
>     coremaker_data = coremaker_ro + 1;
> !   abort ();
>   }
>   
>   void
>   func1 ()
>   {
> !   func2 ();
>   }
>   
>   int main ()
> --- 104,138 ----
>     for (i = 0; i < 5; i++)
>       coremaker_bss += coremaker_local[i];
>     coremaker_data = coremaker_ro + 1;
> ! 
> !   /* This function used to simply call `abort' unconditionally.
> !      However, because GCC sometimes knows that `abort' will never
> !      return, the `call' instruction that invokes `abort' would
> !      sometimes be the very last instruction in this function.  The
> !      epilogue instructions you'd normally expect --- deallocating the
> !      frame, jumping to the return address --- were omitted, since
> !      they'd never be reached anyway.  This means that the return
> !      address passed to abort (which it'll never use) actually points
> !      beyond the end of the caller!  Sometimes the return address
> !      seemed to be in the next function; sometimes it seemed to be in
> !      padding instructions between functions, for which there was no
> !      line number info.  In any case, GDB had difficulties producing a
> !      backtrace in this case.
> ! 
> !      There's no way to force the compiler not to put the call to
> !      `abort' at the very end of the function --- after all, it is
> !      functionally correct to do so.  But we hope that putting it in a
> !      conditional will make it more likely that GDB can get a
> !      backtrace, and find coremaker_local, which is what we really care
> !      about.  */
> !   if (please_abort)
> !     abort ();
>   }
>   
>   void
>   func1 ()
>   {
> !   func2 (1);
>   }
>   
>   int main ()
> 
> 

Re: RFA: try to ensure abort has valid return address

[Fernando Nasser]

I wonder if we will always be able to trick the compiler with
this, but it is worthy of a try.

Approved.

Thanks Jim.
Fernando

Jim Blandy wrote:
> 
> 2002-01-12  Jim Blandy  <jimb@redhat.com>
> 
>         * gdb.base/coremaker.c (func2): Try to arrange for the return
>         address passed to `abort' to fall within `func2', so we can get
>         backtraces.
> 
> Index: gdb/testsuite/gdb.base/coremaker.c
> ===================================================================
> RCS file: /cvs/cvsfiles/devo/gdb/testsuite/gdb.base/coremaker.c,v
> retrieving revision 1.4
> diff -c -r1.4 coremaker.c
> *** gdb/testsuite/gdb.base/coremaker.c  1999/06/25 23:44:28     1.4
> --- gdb/testsuite/gdb.base/coremaker.c  2002/01/12 06:42:09
> ***************
> *** 81,87 ****
>   }
> 
>   void
> ! func2 ()
>   {
>     int coremaker_local[5];
>     int i;
> --- 81,87 ----
>   }
> 
>   void
> ! func2 (int please_abort)
>   {
>     int coremaker_local[5];
>     int i;
> ***************
> *** 104,116 ****
>     for (i = 0; i < 5; i++)
>       coremaker_bss += coremaker_local[i];
>     coremaker_data = coremaker_ro + 1;
> !   abort ();
>   }
> 
>   void
>   func1 ()
>   {
> !   func2 ();
>   }
> 
>   int main ()
> --- 104,138 ----
>     for (i = 0; i < 5; i++)
>       coremaker_bss += coremaker_local[i];
>     coremaker_data = coremaker_ro + 1;
> !
> !   /* This function used to simply call `abort' unconditionally.
> !      However, because GCC sometimes knows that `abort' will never
> !      return, the `call' instruction that invokes `abort' would
> !      sometimes be the very last instruction in this function.  The
> !      epilogue instructions you'd normally expect --- deallocating the
> !      frame, jumping to the return address --- were omitted, since
> !      they'd never be reached anyway.  This means that the return
> !      address passed to abort (which it'll never use) actually points
> !      beyond the end of the caller!  Sometimes the return address
> !      seemed to be in the next function; sometimes it seemed to be in
> !      padding instructions between functions, for which there was no
> !      line number info.  In any case, GDB had difficulties producing a
> !      backtrace in this case.
> !
> !      There's no way to force the compiler not to put the call to
> !      `abort' at the very end of the function --- after all, it is
> !      functionally correct to do so.  But we hope that putting it in a
> !      conditional will make it more likely that GDB can get a
> !      backtrace, and find coremaker_local, which is what we really care
> !      about.  */
> !   if (please_abort)
> !     abort ();
>   }
> 
>   void
>   func1 ()
>   {
> !   func2 (1);
>   }
> 
>   int main ()

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: RFA: try to ensure abort has valid return address

[Jim Blandy]

Fernando Nasser <fnasser@redhat.com> writes:
> I wonder if we will always be able to trick the compiler with
> this, but it is worthy of a try.

As the comment says, it won't always work.

> Approved.

Committed, thanks.