From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2272 invoked by alias); 4 May 2008 11:53:05 -0000 Received: (qmail 2262 invoked by uid 22791); 4 May 2008 11:53:05 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate4.de.ibm.com (HELO mtagate4.de.ibm.com) (195.212.29.153) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 04 May 2008 11:52:43 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.8/8.13.8) with ESMTP id m44Bqcte052176 for ; Sun, 4 May 2008 11:52:38 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m44BqbEX1867942 for ; Sun, 4 May 2008 13:52:37 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m44BqbVh011167 for ; Sun, 4 May 2008 13:52:37 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id m44Bqb1q011164; Sun, 4 May 2008 13:52:37 +0200 Message-Id: <200805041152.m44Bqb1q011164@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Sun, 4 May 2008 13:52:37 +0200 Subject: Re: [commit] Fix backtrace past "clone" on powerpc To: mark.kettenis@xs4all.nl (Mark Kettenis) Date: Sun, 04 May 2008 13:14:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <200805040904.m4494C2X021017@brahms.sibelius.xs4all.nl> from "Mark Kettenis" at May 04, 2008 11:04:12 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-05/txt/msg00166.txt.bz2 Mark Kettenis wrote: > > Date: Sun, 4 May 2008 02:43:13 +0200 (CEST) > > From: "Ulrich Weigand" > > > > 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