From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3754 invoked by alias); 3 Dec 2004 18:49:09 -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 3663 invoked from network); 3 Dec 2004 18:49:04 -0000 Received: from unknown (HELO priv-edtnes56.telusplanet.net) (199.185.220.220) by sourceware.org with SMTP; 3 Dec 2004 18:49:04 -0000 Received: from takamaka.act-europe.fr ([142.179.108.108]) by priv-edtnes56.telusplanet.net (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP id <20041203184904.PHAC19463.priv-edtnes56.telusplanet.net@takamaka.act-europe.fr>; Fri, 3 Dec 2004 11:49:04 -0700 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 799E447DA6; Fri, 3 Dec 2004 10:49:03 -0800 (PST) Date: Fri, 03 Dec 2004 18:49:00 -0000 From: Joel Brobecker To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] Infinite backtraces... Message-ID: <20041203184903.GH16491@adacore.com> References: <20041202224606.GL994@adacore.com> <41B0AFED.5050803@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41B0AFED.5050803@gnu.org> User-Agent: Mutt/1.4i X-SW-Source: 2004-12/txt/msg00077.txt.bz2 > 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 :-( That's pretty much what I have done as a proof of concept. I ran it through the testsuite on our HP machine, and we got 3 new passes (from 3 unresolved, due to the expect buffer filling up). > 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. > 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) And then, after building each new frame, we display the information for that new 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? -- Joel