From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22528 invoked by alias); 24 Nov 2005 17:29:06 -0000 Received: (qmail 22519 invoked by uid 22791); 24 Nov 2005 17:29:06 -0000 X-Spam-Check-By: sourceware.org Received: from fra-del-01.spheriq.net (HELO fra-del-01.spheriq.net) (195.46.51.97) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 24 Nov 2005 17:29:04 +0000 Received: from fra-out-02.spheriq.net (fra-out-02.spheriq.net [195.46.51.130]) by fra-del-01.spheriq.net with ESMTP id jAOHT04a012900 for ; Thu, 24 Nov 2005 17:29:00 GMT Received: from fra-cus-01.spheriq.net (fra-cus-01.spheriq.net [195.46.51.37]) by fra-out-02.spheriq.net with ESMTP id jAOHSxuu030847 for ; Thu, 24 Nov 2005 17:28:59 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by fra-cus-01.spheriq.net with ESMTP id jAOHSnNe024709 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 24 Nov 2005 17:28:53 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id DD8E4DA44; Thu, 24 Nov 2005 17:28:48 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id EF6D447479; Thu, 24 Nov 2005 17:31:50 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 8E9F375999; Thu, 24 Nov 2005 17:31:50 +0000 (UTC) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 5E95047470; Thu, 24 Nov 2005 17:31:49 +0000 (GMT) Received: from [164.129.15.13] (terrorhawk.bri.st.com [164.129.15.13]) by mail1.bri.st.com (MOS 3.5.8-GR) with ESMTP id CGZ96654 (AUTH "andrew stubbs"); Thu, 24 Nov 2005 17:28:45 GMT Message-ID: <4385F7A0.5070907@st.com> Date: Thu, 24 Nov 2005 22:48:00 -0000 From: Andrew STUBBS User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 To: Andrew Stubbs Cc: Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: [SH][PATCH] Disable ABI frame sniffer References: <43722DEF.8060300@st.com> <20051110013122.GB11334@nevyn.them.org> <437321EE.7010904@st.com> <20051110133905.GB21420@nevyn.them.org> <43735A1D.6010406@st.com> <20051110231336.GB3195@nevyn.them.org> <4374863D.60601@st.com> <20051113183624.GE3599@nevyn.them.org> <4384B6B5.90207@st.com> In-Reply-To: <4384B6B5.90207@st.com> Content-Type: multipart/mixed; boundary="------------010506020804020601090004" X-O-Spoofed: Not Scanned X-O-General-Status: No X-O-Spam1-Status: Not Scanned X-O-Spam2-Status: Not Scanned X-O-URL-Status: Not Scanned X-O-Virus1-Status: No X-O-Virus2-Status: Not Scanned X-O-Virus3-Status: No X-O-Virus4-Status: No X-O-Virus5-Status: Not Scanned X-O-Image-Status: Not Scanned X-O-Attach-Status: Not Scanned X-SpheriQ-Ver: 4.2.0 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2005-11/txt/msg00445.txt.bz2 This is a multi-part message in MIME format. --------------010506020804020601090004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1466 Andrew Stubbs wrote: > I could modify the sh sniffer such that it actually does something. > However, this would require modifying frame_unwind_find_by_frame() and > family such that it can accept a NULL answer from every sniffer. This won't work. The whole unwinding mechanism is lazy and does not happen until print_frame_info() has already committed to printing something, it just doesn't know what yet. The reason for this is that get_prev_frame() and get_prev_frame_1() have already effectively promised that there will be another frame, but haven't actually ventured to find out what it is - that is done lazily as required. It isn't possible to have the sniffer say 'I know this is the last frame on the stack' because, unless the compiler says so, all it really could tell is that this is the last frame as it knows it. It might work if the code asked all the sniffers and returned 'end of stack' if all of them fail to recognise a frame. But, all is not lost .... The attached patch to get_prev_frame_1() *does* fix the problem. With this I get exactly what I want. I have no doubt that it is somehow horribly flawed and totally unacceptable, but hopefully something will emerge from all this. BTW, the file has a comment that says 'Allocate the new frame but do not wire it in to the frame chain', but then it appears to go ahead and wire up the frame chain. Is this a mistake or am I just misunderstanding it? Thanks Andrew Stubbs --------------010506020804020601090004 Content-Type: text/plain; name="unwinder.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="unwinder.patch" Content-length: 977 2005-11-24 Andrew Stubbs * frame.c (get_prev_frame_1): Check the PC is within the program before allowing the frame to be created. Index: src/gdb/frame.c =================================================================== --- src.orig/gdb/frame.c 2005-11-24 16:45:22.000000000 +0000 +++ src/gdb/frame.c 2005-11-24 17:24:09.000000000 +0000 @@ -1123,6 +1123,16 @@ get_prev_frame_1 (struct frame_info *thi this_frame->prev = prev_frame; prev_frame->next = this_frame; + /* Check that the new frame would refer to a location within the + program. This has to be done after it is linked in or the + function calls will not work. If the location is junk then + we have probably dropped off the bottom of the stack. */ + if (!find_pc_section (frame_unwind_address_in_block (this_frame))) + { + this_frame->prev = NULL; + return NULL; + } + if (frame_debug) { fprintf_unfiltered (gdb_stdlog, "-> "); --------------010506020804020601090004--