From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26629 invoked by alias); 23 Nov 2005 18:39:36 -0000 Received: (qmail 26619 invoked by uid 22791); 23 Nov 2005 18:39:35 -0000 X-Spam-Check-By: sourceware.org Received: from lon-del-03.spheriq.net (HELO lon-del-03.spheriq.net) (195.46.50.99) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 23 Nov 2005 18:39:33 +0000 Received: from lon-out-02.spheriq.net ([195.46.50.130]) by lon-del-03.spheriq.net with ESMTP id jANIdVfC007254 for ; Wed, 23 Nov 2005 18:39:31 GMT Received: from lon-cus-01.spheriq.net (lon-cus-01.spheriq.net [195.46.50.37]) by lon-out-02.spheriq.net with ESMTP id jANIdUp0009976 for ; Wed, 23 Nov 2005 18:39:30 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-01.spheriq.net with ESMTP id jANIdT9T025669 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 23 Nov 2005 18:39:29 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 41BD3DA41; Wed, 23 Nov 2005 18:39:29 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id 0D035474AD; Wed, 23 Nov 2005 18:42:31 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id BE75275995; Wed, 23 Nov 2005 18:42:30 +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 4EC08474AA; Wed, 23 Nov 2005 18:42:30 +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 CGZ88039 (AUTH "andrew stubbs"); Wed, 23 Nov 2005 18:39:27 GMT Message-ID: <4384B6B5.90207@st.com> Date: Wed, 23 Nov 2005 19:52:00 -0000 From: Andrew STUBBS User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 To: Daniel Jacobowitz Cc: 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> In-Reply-To: <20051113183624.GE3599@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00436.txt.bz2 Daniel Jacobowitz wrote: > - Add a way for a sniffer to indicate "I do recognize how to unwind > this frame, but I recognize it as the end of the stack" to solve > the current off-by-one problem. This could be quite nice... I don't want to mess with the OS or compiler to fix this problem so I have been looking into this suggestion (or at least something in GDB alone). I started by trying to figure out why the dwarf unwinder appeared to be giving: #2 0xdeaddead in ?? () It turns out that this does not come from here at all - the dwarf sniffer rejects the frame, and yet I thought I had the SH unwinder disabled, so why did it still come out? In fact, the order of events is (and apologise to all those who know this stuff backwards): dwarf sniffer sh sniffer print message sh 'frame this id' (where I had disabled the unwinder). The obvious thing to do appears to be to disable it in the sh sniffer, but if I have that return NULL, as the dwarf unwinder does, I get an internal error. Not only may this sniffer never reject *any* frame, it is not possible to remove it altogether (i.e. not register it in the first place), because you still get the internal error. I must conclude therefore that it is not currently possible to reject any 'frame' which precedes (from the point of view of the program) a frame with debug information. My question is 'where to go from here?' The above suggestion would require modifying the dwarf sniffer (since the last frame on the stack has dwarf). I can't easily see how to do this because the dwarf data doesn't know it is the end of the stack and unwinding any further seems problematic. 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. There is, of course, the question of how to detect the end of the stack, short of just searching for the specific case. I could check if it is in memory, but that seems problematic at best - for one thing it assumes we know where memory is. Perhaps I could see if it is in a loaded section? Any other suggestions? Thanks Andrew Stubbs