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

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

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