From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23968 invoked by alias); 21 Aug 2006 11:35:04 -0000 Received: (qmail 23959 invoked by uid 22791); 21 Aug 2006 11:35:04 -0000 X-Spam-Check-By: sourceware.org Received: from mail.imc-berlin.de (HELO mail.imc-berlin.de) (217.110.46.186) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 21 Aug 2006 11:35:01 +0000 Received: from mailserver.berlin.imc-berlin.de (mailserver.berlin.imc-berlin.de [10.0.0.19]) by mail.imc-berlin.de (Postfix) with ESMTP id 02D882F02A for ; Mon, 21 Aug 2006 14:29:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mailserver.berlin.imc-berlin.de (Postfix) with ESMTP id 79880A23B for ; Mon, 21 Aug 2006 13:34:57 +0200 (CEST) Received: from [10.0.2.29] (zarges.berlin.imc-berlin.de [10.0.2.29]) by mailserver.berlin.imc-berlin.de (Postfix) with ESMTP id 958DEA26E for ; Mon, 21 Aug 2006 13:34:56 +0200 (CEST) Message-ID: <44E999B4.5030905@imc-berlin.de> Date: Mon, 21 Aug 2006 11:35:00 -0000 From: "Zarges, Olav" User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "gdb@sourceware.org" Subject: Re: gdb-6.5 produces infinite backtrace on ARM References: <44E181DE.7040905@imc-berlin.de> <20060815124053.GA18496@nevyn.them.org> <20060819052434.GA15612@nevyn.them.org> In-Reply-To: <20060819052434.GA15612@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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-08/txt/msg00151.txt.bz2 Daniel Jacobowitz wrote: > [ ... ] > 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. Sounds pretty good. Good job! I can't wait to lay my hands on the patch... Another question arose from you answer: what is a gdb/mi front-end supposed to do when a message like "Backtrace stopped: frame did not save the PC" or "Previous frame identical to this frame (corrupt stack?)" or ... is returned at the end of the backtrace? Eclipse just throws away the complete backtrace for the corresponding thread.