From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6662 invoked by alias); 25 Feb 2008 12:03:41 -0000 Received: (qmail 6583 invoked by uid 22791); 25 Feb 2008 12:03:38 -0000 X-Spam-Check-By: sourceware.org Received: from dmz.mips-uk.com (HELO dmz.mips-uk.com) (194.74.144.194) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 25 Feb 2008 12:03:20 +0000 Received: from internal-mx1 ([192.168.192.240] helo=ukservices1.mips.com) by dmz.mips-uk.com with esmtp (Exim 3.35 #1 (Debian)) id 1JTc3A-0001zz-00; Mon, 25 Feb 2008 12:03:16 +0000 Received: from perivale.mips.com ([192.168.192.200]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1JTc34-000062-00; Mon, 25 Feb 2008 12:03:10 +0000 Received: from macro (helo=localhost) by perivale.mips.com with local-esmtp (Exim 4.63) (envelope-from ) id 1JTc33-0000AB-UC; Mon, 25 Feb 2008 12:03:09 +0000 Date: Mon, 25 Feb 2008 19:19:00 -0000 From: "Maciej W. Rozycki" To: Daniel Jacobowitz cc: gdb-patches@sourceware.org, Nigel Stephens , "Maciej W. Rozycki" Subject: Re: Do not unwind frames past NULL PC In-Reply-To: Message-ID: References: <20080222172056.GA1693@caradoc.them.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MIPS-Technologies-UK-MailScanner: Found to be clean X-MIPS-Technologies-UK-MailScanner-From: macro@mips.com 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-02/txt/msg00373.txt.bz2 On Fri, 22 Feb 2008, Maciej W. Rozycki wrote: > Hmm, it looks it has been discussed deeply and fiercely enough for me not > to dare question the outcome (or the lack of), but given the situation > wouldn't it be reasonable to place a comment within the code of this > function stating that outermost frame determination has been deliberately > omitted so that cases like stack corruption are easier for people to > debug? OK, here is the patch. I hope I have gathered the intent from the discussions correctly and expressed it clearly enough. Personally I think for MIPS there is no gain from printing a frame with a zero PC. As for MIPS the frame is associated with the PC, there will never be further backtrace past a zero PC, because there will never be a frame described for the code address of zero. So whether the dangling "frame" is displayed or not makes no difference -- unless there is an error reported with a backtrace, the null PC will always be there. I recognise that other architectures may have a different view on the frames though. 2008-02-25 Maciej W. Rozycki * frame.c (get_prev_frame_1): Add a note about unwillingness to check for the outermost frame. OK to apply? Maciej gdb-get_prev_frame.diff Index: binutils-quilt/src/gdb/frame.c =================================================================== --- binutils-quilt.orig/src/gdb/frame.c 2008-02-25 10:42:37.000000000 +0000 +++ binutils-quilt/src/gdb/frame.c 2008-02-25 11:48:56.000000000 +0000 @@ -1250,6 +1250,14 @@ } } + /* This is the place where a check for the ABI-specific condition + denoting the outermost frame could be done. We do not do this + though, quite deliberately, because we have no means to verify + whether this condition would be intentional or a result of a + possible stack corruption. If the latter was the case we would + remove information from output which for some ABIs could + provide a hint that a stack corruption actually happened. */ + /* Allocate the new frame but do not wire it in to the frame chain. Some (bad) code in INIT_FRAME_EXTRA_INFO tries to look along frame->next to pull some fancy tricks (of course such code is, by