From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26277 invoked by alias); 3 Dec 2004 18:28:40 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 25900 invoked from network); 3 Dec 2004 18:28:30 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 3 Dec 2004 18:28:30 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id iB3ISPuF018101 for ; Fri, 3 Dec 2004 13:28:25 -0500 Received: from localhost.redhat.com (vpn50-46.rdu.redhat.com [172.16.50.46]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iB3IS9r24821; Fri, 3 Dec 2004 13:28:09 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id D9625969F2; Fri, 3 Dec 2004 13:26:56 -0500 (EST) Message-ID: <41B0AFED.5050803@gnu.org> Date: Fri, 03 Dec 2004 18:28:00 -0000 From: Andrew Cagney User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) MIME-Version: 1.0 To: Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] Infinite backtraces... References: <20041202224606.GL994@adacore.com> In-Reply-To: <20041202224606.GL994@adacore.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-12/txt/msg00076.txt.bz2 Joel Brobecker wrote: > Hello, > > I have been studying the few examples I have here where GDB creates > an endless backtrace when we do a "bt". There is also the case that > Randolph exposed, but I think his case was a bit particular. > > Still staying on hppa, I have the following example (code copied at > the end of this message). What the code does is create one task that > will call a null procedure Break_Me. We put the breakpoint on that > procedure, and run until we hit that breakpoint, and then do a backtrace. > Because we're inside a task, the call stack does not start at the entry > point nor does it contain a call to the "main" procedure. FYI, I've a finish up a patch that checks for this: > #6 0x7aee0f08 in __pthread_create_system () from /usr/lib/libpthread.1 > #7 0x00000000 in ?? () I.e., a zero pc unwound from a normal frame. It is ``tricky'' to test though :-( The other thing that would help here is for glibc's CFI to identify the return-address (and CFA) column as unknown (assuming I've got my CFI term correct) on the outer most frame. It would then be easy for dwarf2-unwind to identify this. It's been discussed, agreed, but not implemented. > I am not sure I have a sufficiently high-level view of the entire > code that is involved in unwinding, but it seemed to me that we need > to add a new architecture-dependent hook that would tell whether a > given frame is the initial one, and that unwinding can not be done > past this frame. This naturally pointed to a new gdbarch method. > > Something like gdbarch_upper_most_frame_p (....), with a default > value that would always return false. > > And then, in get_prev_frame_1, either right after we check for > this_frame->prev_p, or slightly after we get the ID of this_frame, > we can add a call to this new method. > > I am still doing some researching about this, but I think that on > hppa, the RP will always be initialized to 0 in the upper most frame. > So we can stop the unwinding using that condition. Right, but it shouldn't need an additional method. The per-architecture unwinder, when it detects a frame that the ABI specifies as final, should return a null frame ID. For instance, the PPC ABI explicitly specifies that it's stack be terminated with a zero SP. Finally, a more long term suggestion is that we add a mechanism for creating or adding attributes to symbols (for instance for signal trampolines). An atribute of such a symbol could be that it is outermost. Want to help fill these gaps? Andrew