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

Mark Kettenis
2008-05-04T09:05:42Z

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