From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23324 invoked by alias); 10 Nov 2005 19:18:39 -0000 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 Received: (qmail 23289 invoked by uid 22791); 10 Nov 2005 19:18:36 -0000 Received: from lon-del-02.spheriq.net (HELO lon-del-02.spheriq.net) (195.46.50.98) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 10 Nov 2005 19:18:36 +0000 Received: from lon-out-01.spheriq.net ([195.46.50.129]) by lon-del-02.spheriq.net with ESMTP id jAAJIYBd004957 for ; Thu, 10 Nov 2005 19:18:34 GMT Received: from lon-cus-02.spheriq.net (lon-cus-02.spheriq.net [195.46.50.38]) by lon-out-01.spheriq.net with ESMTP id jAAJIVau004036 for ; Thu, 10 Nov 2005 19:18:33 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-02.spheriq.net with ESMTP id jAAJIUH8004030 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 10 Nov 2005 19:18:31 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 C38DFDA42; Thu, 10 Nov 2005 19:18:25 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id E0FDC475B0; Thu, 10 Nov 2005 19:21:21 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 9FBD675995; Thu, 10 Nov 2005 19:21:21 +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 2A37B47349; Thu, 10 Nov 2005 19:21:21 +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 CGW01342 (AUTH "andrew stubbs"); Thu, 10 Nov 2005 19:18:24 GMT Message-ID: <43739C74.6020000@st.com> Date: Thu, 10 Nov 2005 23:13: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> In-Reply-To: <43735A1D.6010406@st.com> 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.1.07 X-SW-Source: 2005-11/txt/msg00138.txt.bz2 > I'm currently in the process of trying to patch GDB HEAD sufficiently to > run OS21 threaded programs on ST targets like I do with our 6.3 based > tools. When I've got that done I'll have a better idea whether anything > needs to be done any more. I suspect we will still _like_ to. The following shows the difference between the unwinder enabled and disabled: (gdb) thread apply all bt Thread 7 (Thread 7): #0 _md_kernel_task_launch (entry_point=0x9, datap=0x8) at src/st40/kernel/kernel.c:164 #1 0xdeaddead in ?? () #2 0xdeaddead in ?? () Previous frame identical to this frame (corrupt stack?) Thread 6 (Thread 6): #0 _md_kernel_task_launch (entry_point=0x9, datap=0x8) at src/st40/kernel/kernel.c:164 #1 0xdeaddead in ?? () #2 0xdeaddead in ?? () Previous frame identical to this frame (corrupt stack?) Thread 5 (Thread 5): #0 _md_kernel_task_launch (entry_point=0x9, datap=0x8) at src/st40/kernel/kernel.c:164 #1 0xdeaddead in ?? () #2 0xdeaddead in ?? () Previous frame identical to this frame (corrupt stack?) Thread 4 (Thread 4): #0 _md_kernel_task_launch (entry_point=0x9, datap=0x8) at src/st40/kernel/kernel.c:164 #1 0xdeaddead in ?? () #2 0xdeaddead in ?? () Previous frame identical to this frame (corrupt stack?) Thread 3 (Thread 3): #0 _md_kernel_task_launch (entry_point=0x9, datap=0x8) at src/st40/kernel/kernel.c:164 #1 0xdeaddead in ?? () #2 0xdeaddead in ?? () Previous frame identical to this frame (corrupt stack?) Thread 2 (Thread 2): #0 _md_kernel_task_launch (entry_point=0x9, datap=0x8) at src/st40/kernel/kernel.c:164 #1 0xdeaddead in ?? () #2 0xdeaddead in ?? () Previous frame identical to this frame (corrupt stack?) Thread 1 (Thread 1): #0 main () at /home/afra/users/stubbsa/os21test.c:30 (gdb) set backtrace abi-sniffer off (gdb) thread apply all bt Thread 7 (Thread 7): #0 _md_kernel_task_launch (entry_point=0x9, datap=0x8) at src/st40/kernel/kernel.c:164 #1 0xdeaddead in ?? () Thread 6 (Thread 6): #0 _md_kernel_task_launch (entry_point=0x9, datap=0x8) at src/st40/kernel/kernel.c:164 #1 0xdeaddead in ?? () Thread 5 (Thread 5): #0 _md_kernel_task_launch (entry_point=0x9, datap=0x8) at src/st40/kernel/kernel.c:164 #1 0xdeaddead in ?? () Thread 4 (Thread 4): #0 _md_kernel_task_launch (entry_point=0x9, datap=0x8) at src/st40/kernel/kernel.c:164 #1 0xdeaddead in ?? () Thread 3 (Thread 3): #0 _md_kernel_task_launch (entry_point=0x9, datap=0x8) at src/st40/kernel/kernel.c:164 #1 0xdeaddead in ?? () Thread 2 (Thread 2): #0 _md_kernel_task_launch (entry_point=0x9, datap=0x8) at src/st40/kernel/kernel.c:164 #1 0xdeaddead in ?? () Thread 1 (Thread 1): #0 main () at /home/afra/users/stubbsa/os21test.c:30 The situation clearly has improved since 6.3, but I'm still not happy about giving a debugger with this behaviour to our customers. Unfortunately I have been unable to test how eclipse reacts to the error message due to a mysterious seg fault in ui_file_put() when using -i=mi1 (but not mi2) after the first 'Loading section' message. Apparently '0x19' isn't a useful value for 'file'. Something to look forward to tomorrow. BFN Andrew