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

[Mark Kettenis <mark dot kettenis at xs4all dot nl>]

> 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
>