From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23649 invoked by alias); 25 Mar 2015 07:35:51 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 23636 invoked by uid 89); 25 Mar 2015 07:35:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL autolearn=ham version=3.3.2 X-HELO: sasl.smtp.pobox.com Received: from pb-sasl1.int.icgroup.com (HELO sasl.smtp.pobox.com) (208.72.237.25) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 25 Mar 2015 07:35:48 +0000 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 49F3C3A160; Wed, 25 Mar 2015 03:35:46 -0400 (EDT) Received: from pb-sasl1.int.icgroup.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 3A8E63A15F; Wed, 25 Mar 2015 03:35:46 -0400 (EDT) Received: from rusty (unknown [88.160.190.192]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-sasl1.pobox.com (Postfix) with ESMTPSA id 6B6E13A15E; Wed, 25 Mar 2015 03:35:44 -0400 (EDT) From: Andy Wingo To: Doug Evans Cc: Alexander Smundak , gdb-patches Subject: Re: Unwinding through multiple stacks References: Date: Wed, 25 Mar 2015 07:35:00 -0000 In-Reply-To: (Doug Evans's message of "Tue, 24 Mar 2015 17:00:07 -0700") Message-ID: <87y4ml1qcy.fsf@igalia.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: 8C80ED12-D2C1-11E4-9009-99D0625725FD-02397024!pb-sasl1.pobox.com X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg00822.txt.bz2 Hi, On Wed 25 Mar 2015 01:00, Doug Evans writes: > A topic came up on #gdb that the current patches don't cover. > What if the frame we're trying to unwind through has a different > stack? I was wondering about this too. IIUC this check from GDB isn't a fundamental limitation -- it's just a convenience for the user, that we don't keep trying to compute outer frames for what looks to be a corrupt stack. In these cases I would have the unwinder mark the frame as not needing an UNWIND_INNER_ID check. Having the check by default is still useful IMO. How about (unwind-info-set-discontiguous! unwind-info #t) or something. That would eventually cause the frame_id to have a "discontiguous" bitfield marked as 1. To me it seems appropriate for a followup patch. WDYT? Andy