From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14714 invoked by alias); 19 Sep 2006 01:40:01 -0000 Received: (qmail 14705 invoked by uid 22791); 19 Sep 2006 01:40:00 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.palmsource.com (HELO mx2.palmsource.com) (12.7.175.14) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 19 Sep 2006 01:39:58 +0000 Received: from localhost (localhost [127.0.0.1]) by localhost.domain.tld (Postfix) with ESMTP id A5CF02623E; Mon, 18 Sep 2006 18:39:56 -0700 (PDT) Received: from mx2.palmsource.com ([127.0.0.1]) by localhost (mx2.palmsource.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 09299-04-3; Mon, 18 Sep 2006 18:39:55 -0700 (PDT) Received: from ussunex01.palmsource.com (unknown [192.168.101.9]) by mx2.palmsource.com (Postfix) with ESMTP id 5C60B261D0; Mon, 18 Sep 2006 18:39:55 -0700 (PDT) Received: from 192.168.92.59 ([192.168.92.59]) by ussunex01.palmsource.com ([192.168.101.9]) via Exchange Front-End Server owa.palmsource.com ([10.0.20.17]) with Microsoft Exchange Server HTTP-DAV ; Tue, 19 Sep 2006 01:39:54 +0000 Received: from svmsnyderlnx by owa.palmsource.com; 18 Sep 2006 18:39:54 -0700 Subject: Re: gdb-6.5 produces infinite backtrace on ARM From: Michael Snyder To: Daniel Jacobowitz Cc: "Zarges, Olav" , "gdb@sourceware.org" , msnyder@sonic.net In-Reply-To: <20060819052434.GA15612@nevyn.them.org> References: <44E181DE.7040905@imc-berlin.de> <20060815124053.GA18496@nevyn.them.org> <20060819052434.GA15612@nevyn.them.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 19 Sep 2006 01:40:00 -0000 Message-Id: <1158629994.20759.4.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-09/txt/msg00097.txt.bz2 On Sat, 2006-08-19 at 01:24 -0400, Daniel Jacobowitz wrote: > On Tue, Aug 15, 2006 at 08:40:54AM -0400, Daniel Jacobowitz wrote: > > Normally you should get an ugly end of the backtrace, not an infinite > > one. If you'd like, I can take a look at what's gone wrong. I would > > need enough to reproduce the problem - which probably means a tarball > > including the source, compiled executable, and shared libraries which > > it uses, since this may be specific to something about your build > > environment. If you want to do that, let me know; it's too big to post > > to the list. > > Thanks a lot for the test case. The underlying cause was that > pthread_start_thread is marked noreturn; GCC seems to have omitted > the LR register save in this case. I thought it wouldn't do that, > but in any case, we should cope. > > I know have a fairly general patch set for this problem, which > produces: > > (gdb) bt > ... > #4 0xxxxxxxx in pthread_start_thread () from /lib/libpthread.so.0 > Backtrace stopped: frame did not save the PC > (gdb) > > This isn't ideal - we could detect the pthread_start_thread function > name and stop automatically, which might be a wise addition - but it's > better than going off into the woods. > > There's about 250 lines of changes involved, to one of the more > complicated parts of GDB, so I will need to go over the patches again > and post them separately. But I'll try to make sure this is fixed > soon. Daniel, did you ever get around to posting your patch? I have now run into this self-same problem myself, and would be glad to work with you on getting it handled. Rather not duplicate effort, though... Thanks, Michael