From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24999 invoked by alias); 22 Feb 2008 18:31:50 -0000 Received: (qmail 24990 invoked by uid 22791); 22 Feb 2008 18:31:49 -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; Fri, 22 Feb 2008 18:31:22 +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 1JScg2-0001ga-00; Fri, 22 Feb 2008 18:31:18 +0000 Received: from perivale.mips.com ([192.168.192.200]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1JScfv-0003uH-00; Fri, 22 Feb 2008 18:31:11 +0000 Received: from macro (helo=localhost) by perivale.mips.com with local-esmtp (Exim 4.63) (envelope-from ) id 1JScfv-0003lI-3a; Fri, 22 Feb 2008 18:31:11 +0000 Date: Fri, 22 Feb 2008 19:50: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: <20080222172056.GA1693@caradoc.them.org> 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/msg00361.txt.bz2 On Fri, 22 Feb 2008, Daniel Jacobowitz wrote: > Similar changes have been proposed several times, but were controversial. > > http://sourceware.org/ml/gdb-patches/2006-05/msg00196.html > http://sourceware.org/ml/gdb-patches/2006-07/msg00296.html > > and more recently: > > http://sourceware.org/ml/gdb-patches/2007-12/msg00004.html 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? Maciej