From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3388 invoked by alias); 3 Dec 2004 19:26:44 -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 3355 invoked from network); 3 Dec 2004 19:26:40 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 3 Dec 2004 19:26:40 -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 iB3JQYUv002668 for ; Fri, 3 Dec 2004 14:26:40 -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 iB3JQXr08722; Fri, 3 Dec 2004 14:26:33 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 8A3AA969F2; Fri, 3 Dec 2004 14:25:20 -0500 (EST) Message-ID: <41B0BD9D.8040603@gnu.org> Date: Fri, 03 Dec 2004 19:26: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> <41B0AFED.5050803@gnu.org> <20041203184903.GH16491@adacore.com> In-Reply-To: <20041203184903.GH16491@adacore.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-12/txt/msg00079.txt.bz2 >>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. > > > This is of course a good solution, provided that you can use dwarf2. > On 32bit HP/UX, we're stuck. Doh! >>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. > > > I am not sure this is doable. Is it? Let me check that again. Perhaps > it's ok to create the frame object, but then later compute a null frame > ID for it? As far as I remember, the sequence of events is like this > when trying to build the frame chain: > > . get_prev_frame (this_frame): > . get_frame_id (this_frame) > . frame_id (next_frame, this_cache) > . check this frame ID > . build previous frame > (frame ID unset) Yes, gdb already creates the frame object and then later constructs the frame ID. The build has been reduced to: prev_frame = malloc (); prev_frame->next = this_frame; return prev_frame; Also note that, unlike the past, the frame ID is separate to the ``frame base'' the former can be NULL while the later is still valid. > And then, after building each new frame, we display the information > for that new frame. It is what lets us "up" on to an apparently corrupt frame. >>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. > > > But could we determine that a symbol is outermost. And couldn't the > same symbol be used in both contexts? Determining that a symbol is outer-most is somewhat osabi dependant - the arch dependant code would need to register or mark it up as such. Yes, the symbol can be used in both contexts vis: main (argc) { if (argc > 0) main (argc - 1); } but I suspect it is illegal. Andrew