From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100467 invoked by alias); 9 Mar 2015 08:27:08 -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 100456 invoked by uid 89); 9 Mar 2015 08:27:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 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; Mon, 09 Mar 2015 08:27:05 +0000 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 0BAD33325A; Mon, 9 Mar 2015 04:27:03 -0400 (EDT) Received: from pb-sasl1.int.icgroup.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id F22D433259; Mon, 9 Mar 2015 04:27:02 -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 0E43133256; Mon, 9 Mar 2015 04:27:00 -0400 (EDT) From: Andy Wingo To: Doug Evans Cc: gdb-patches , Alexander Smundak , Pedro Alves Subject: Re: Frame sniffers in Python/Guile/* References: <87d24r4jgx.fsf@igalia.com> Date: Mon, 09 Mar 2015 08:27:00 -0000 In-Reply-To: (Doug Evans's message of "Sun, 08 Mar 2015 13:03:13 -0700") Message-ID: <87d24itw2y.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: 0FB39AEC-C636-11E4-93F8-B058D0B8C469-02397024!pb-sasl1.pobox.com X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg00208.txt.bz2 On Sun 08 Mar 2015 21:03, Doug Evans writes: > Andy Wingo writes: >> [...] >> >> And so on. From what I can tell, all of this is because there is no >> selected frame. I recognize that this situation reflects reality in >> some way -- we're still building the selected frame -- but is there any >> way that we could have GDB be in a more "normal" state while the unwind >> callback is running? > > I think one gets into trouble if one tries to > apply the word "normal" to gdb. :-) :-) > I don't have any simple suggestions. Maybe others will. > A lot of times improving/fixing gdb requires first > improving/fixing several other parts first. > Welcome to gdb. :-) Hehe OK :) In this case I came up with what can only be considered a hack, but one which does solve the issue for me. The root of the issue is described in another mail, which I quote: 1. The Guile unwinder's sniffer is called on the innermost frame. That sniffer calls out to Guile. 2. Many actions, for example looking up a symbol without specifying a block. will request the selected frame. 3. get_selected_frame() sees there is no selected frame, and goes to get_current_frame() and will select that. 4. get_current_frame creates a sentinel frame and unwinds that to produce the innermost frame. 5. After unwinding saved registers from the sentinel, frame.c finishes constructing the innermost frame by doing a compute_frame_id() on the frame. 6. compute_frame_id() goes to compute the unwinder for the innermost frame, in order to call the this_id() method, which leads us back to the beginning. http://article.gmane.org/gmane.comp.gdb.patches/105431 The same thing could happen in python on the innermost frame. My terrible solution is somewhat hidden in this patch: http://article.gmane.org/gmane.comp.gdb.patches/105473 The idea is that frame_unwind_find_by_frame detects recursion and signals an error, at least for the innermost frame. (Actually, it should probably error on recursion for any frame; unwinding is iterative, not recursive.) Then get_prev_frame uses the frame_unwind_is_unwinding_innermost_frame() interface to avoid re-unwinding the sentinel frame, and instead returns NULL. Terrible, right? But it does cause get_current_frame to the sentinel frame, allowing get_selected_frame() to succeed, which is at least useful to get the current architecture. Yuck! What does the nice solution look like here? The situation is, no selected frame, we're unwinding the innermost frame, then via Guile/Python/etc something indirectly calls get_selected_frame() in order to get some data from the frame, like the architecture. Do we change all of these to use get_selected_frame_if_set, then fall back to get_current_frame_or_sentinel() ? Andy