[commit] Fix backtrace past "clone" on powerpc

[commit] Fix backtrace past "clone" on powerpc

[Ulrich Weigand]

Hello,

backtrace in multi-threaded applications would tend to throw an error:

where^M
#0  0x0fcfdb34 in sem_wait@GLIBC_2.0 () from /lib/libpthread.so.0^M
#1  0x100008f0 in spin (vp=0x0) at /home/uweigand/fsf/gdb-head/gdb/testsuite/gdb.threads/tls.c:97^M
#2  0x0fcf6764 in start_thread () from /lib/libpthread.so.0^M
#3  0x0ff2c604 in clone () from /lib/libc.so.6^M
Backtrace stopped: previous frame inner to this frame (corrupt stack?)^M

because clone was not recognized to terminate the stack.

The patch below fixes this by having rs6000_frame_this_id return the null
frame ID in that case (just like many other targets do already).

Tested on powerpc-linux and powerpc64-linux; committed to mainline.

Bye,
Ulrich


ChangeLog:

	* rs6000-tdep.c (rs6000_frame_this_id): If info->base is 0,
	return the null frame ID to terminate the backtrace.

diff -urNp gdb-orig/gdb/rs6000-tdep.c gdb-head/gdb/rs6000-tdep.c
--- gdb-orig/gdb/rs6000-tdep.c	2008-05-04 02:07:36.026688000 +0200
+++ gdb-head/gdb/rs6000-tdep.c	2008-05-04 02:08:56.461342375 +0200
@@ -2550,6 +2550,10 @@ rs6000_frame_this_id (struct frame_info 
 {
   struct rs6000_frame_cache *info = rs6000_frame_cache (this_frame,
 							this_cache);
+  /* This marks the outermost frame.  */
+  if (info->base == 0)
+    return;
+
   (*this_id) = frame_id_build (info->base, get_frame_func (this_frame));
 }
 
-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [commit] Fix backtrace past "clone" on powerpc

[Mark Kettenis]

> Date: Sun, 4 May 2008 02:43:13 +0200 (CEST)
> From: "Ulrich Weigand" <uweigand@de.ibm.com>
> 
> Hello,
> 
> backtrace in multi-threaded applications would tend to throw an error:
> 
> where^M
> #0  0x0fcfdb34 in sem_wait@GLIBC_2.0 () from /lib/libpthread.so.0^M
> #1  0x100008f0 in spin (vp=0x0) at /home/uweigand/fsf/gdb-head/gdb/testsuite/gdb.threads/tls.c:97^M
> #2  0x0fcf6764 in start_thread () from /lib/libpthread.so.0^M
> #3  0x0ff2c604 in clone () from /lib/libc.so.6^M
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)^M
> 
> because clone was not recognized to terminate the stack.
> 
> The patch below fixes this by having rs6000_frame_this_id return the null
> frame ID in that case (just like many other targets do already).

Please think a bit more about this.  Is base == 0 a strong enough
condition on PowerPC?  What happens if you have a buffer overflow that
overwrites the piece of the stack where the stack pointer was saved
with zero?  Will the backtrace now terminate without printing an
error?

> diff -urNp gdb-orig/gdb/rs6000-tdep.c gdb-head/gdb/rs6000-tdep.c
> --- gdb-orig/gdb/rs6000-tdep.c	2008-05-04 02:07:36.026688000 +0200
> +++ gdb-head/gdb/rs6000-tdep.c	2008-05-04 02:08:56.461342375 +0200
> @@ -2550,6 +2550,10 @@ rs6000_frame_this_id (struct frame_info 
>  {
>    struct rs6000_frame_cache *info = rs6000_frame_cache (this_frame,
>  							this_cache);
> +  /* This marks the outermost frame.  */
> +  if (info->base == 0)
> +    return;
> +
>    (*this_id) = frame_id_build (info->base, get_frame_func (this_frame));
>  }
>  
> -- 
>   Dr. Ulrich Weigand
>   GNU Toolchain for Linux on System z and Cell BE
>   Ulrich.Weigand@de.ibm.com
> 

Re: [commit] Fix backtrace past "clone" on powerpc

[Ulrich Weigand]

Mark Kettenis wrote:

> > Date: Sun, 4 May 2008 02:43:13 +0200 (CEST)
> > From: "Ulrich Weigand" <uweigand@de.ibm.com>
> > 
> > The patch below fixes this by having rs6000_frame_this_id return the null
> > frame ID in that case (just like many other targets do already).
> 
> Please think a bit more about this.  Is base == 0 a strong enough
> condition on PowerPC?

base == 0 at this point means we read 0 from the stack frame back chain
word.  This condition is in fact defined by the PowerPC ABI to indicate
the top-most stack frame; that's why glibc's clone uses that convention
for the initial frame of the new thread.  There doesn't seem to be any
additional indication of that (if there's no debug info for glibc).

> What happens if you have a buffer overflow that
> overwrites the piece of the stack where the stack pointer was saved
> with zero?  Will the backtrace now terminate without printing an
> error?

I guess that may happen (unless the function in question provides
debug info, in which case we'll use the DWARF-2 unwinder instead of
the prologue-parsing unwinder).  However, in the case of buffer
overflow on the stack all bets are off in any case how the unwinder
will react, depending on what was clobbered ...

I don't think attempting to handle this particular case justifies
treating a correct, ABI-conforming situation as error.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com