From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25668 invoked by alias); 12 Jul 2005 18:32:14 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 25275 invoked by uid 22791); 12 Jul 2005 18:32:05 -0000 Received: from norbert.ecoscentric.com (HELO smtp.ecoscentric.com) (194.153.168.165) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 12 Jul 2005 18:32:05 +0000 Received: by smtp.ecoscentric.com (Postfix, from userid 99) id ECF7565C082; Tue, 12 Jul 2005 19:32:01 +0100 (BST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by smtp.ecoscentric.com (Postfix) with ESMTP id C0D1665C07D; Tue, 12 Jul 2005 19:31:57 +0100 (BST) Message-ID: <42D40C9D.7070204@eCosCentric.com> Date: Tue, 12 Jul 2005 18:32:00 -0000 From: Jonathan Larmour User-Agent: Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513) MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: Thread backtrace termination References: <42D29C67.4070509@eCosCentric.com> <20050711162326.GA32686@nevyn.them.org> <42D2B1CD.2020605@eCosCentric.com> <20050711181907.GA4551@nevyn.them.org> In-Reply-To: <20050711181907.GA4551@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-07/txt/msg00141.txt.bz2 Daniel Jacobowitz wrote: > On Mon, Jul 11, 2005 at 06:52:13PM +0100, Jonathan Larmour wrote: > >>Daniel Jacobowitz wrote: >> >>>On Mon, Jul 11, 2005 at 05:20:55PM +0100, Jonathan Larmour wrote: >>> >>> >>>>The two "global constructors keyed to cyg_scheduler_start" lines are >>>>bogus frame entries, although those also happened with GDB 6.1. The >>>>"corrupt stack" whinge is new, and is treated as an error, including >>>>terminating gdbinit scripts etc. [snip] > The error is caught in the top level code for the backtrace command; > that effectively downgrades it to a warning and backtrace termination. Ah ok, thanks. >>BTW, my other web searches seem to indicate that a fair few (naive) people >>are thinking they are having stack corruption because GDB thinks there >>might be. That's unfortunate. > > > What else would you suggest? GDB is confused. From its point of view, > the stack _is_ corrupt. It's possibly alarmist, but it's no big deal. > Well, the patch was:[snip] > You can find the discussion and sample use on gdb@ a month or two > earlier. Aha, yes, at http://sources.redhat.com/ml/gdb-patches/2005-03/msg00047.html and friends. That seems interesting but somewhat unwieldy, and as you said before, wouldn't apply to compiler generated code. >>>For compiler-generated code there's really no useful way to do this. >> >>I guess atleast now I know that, which saves me spending more time. >> >>Wouldn't it make sense to make such a convention though, such as having a >>return address of 0? > > > This is basically a convention. You could, I suppose, patch a compiler > to generate it. I'm not sure that would be wise. If someone were to come up with an __attribute__ that could be used with GCC to mark functions to be annotated this way, it might be possible. But it's beyond me (or at least, beyond what I have time to get up to speed with) and I doubt anyone else will be that interested. Ho hum. >>Alternatively, how about adding a new command that allows you to define a >>set of entry point symbol names? People can then put an appropriate list >>for themselves or their OS in ~/.gdbinit. Or it can be pre-initialised by >>the OS support within GDB if there is one. e.g. nm-linux.h. Here's what >>I'm thinking of: >> >>set entry-point-name-list main _start _entry >> >>Although handling mangled symbols and multiple languages might be fun. I'm >>not an expert on such things. > > > *shrug* maybe. Well, I'm prepared to create a patch to add such a command if people here think something with that principle would be accepted. Jifl -- eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts --["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine