From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84720 invoked by alias); 9 Mar 2015 19:19:03 -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 84703 invoked by uid 89); 9 Mar 2015 19:19:02 -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 19:19:01 +0000 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 5257F3CC72; Mon, 9 Mar 2015 15:18:59 -0400 (EDT) Received: from pb-sasl1.int.icgroup.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 4A4FA3CC71; Mon, 9 Mar 2015 15:18:59 -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 173963CC6B; Mon, 9 Mar 2015 15:18:57 -0400 (EDT) From: Andy Wingo To: Pedro Alves Cc: gdb-patches , Alexander Smundak , Doug Evans Subject: Re: Frame sniffers in Python/Guile/* References: <87d24r4jgx.fsf@igalia.com> <54FDBE7B.9070405@redhat.com> Date: Mon, 09 Mar 2015 19:19:00 -0000 In-Reply-To: <54FDBE7B.9070405@redhat.com> (Pedro Alves's message of "Mon, 09 Mar 2015 15:38:35 +0000") Message-ID: <87lhj6q8rl.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: 22B36810-C691-11E4-82F2-B058D0B8C469-02397024!pb-sasl1.pobox.com X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg00230.txt.bz2 Hi Pedro, Thanks for the detailed comments! Comments inline and a brief summary at the end. On Mon 09 Mar 2015 16:38, Pedro Alves writes: > On 03/02/2015 01:28 PM, Andy Wingo wrote: > >> Unfortunately, the unwind callback is really squirrely -- you can't do >> much there. > > You mean the "unwind->sniffer" callback, right? If so, that's (so far) by > design. The sniffer callback is only supposed to identify whether > the unwinder can unwind, not do any unwinding at all. :-/ Unfortunately you have to do some unwinding in order to compute a frame ID, and the "unwind->this_id" callback runs in approximately the same environment as the sniffer. > See here for example: > > https://www.sourceware.org/ml/gdb-patches/2013-11/msg00602.html Is it important to use frame_unwind_got_memory et al for results? (IIUC links between values and frames was part of the issue in that mail.) In my unwinders I am just returning values using e.g. (value-dereference (value-cast (ephemeral-frame-read-register ef "rbp") void**-type)) or something similar. If this is important, we will need to provide an interface that looks much more like the unwind interface instead of a simple Maybe :( > But imagine the case of: > > #0 frame0 <<<< current > #1 frame1 <<<< selected > #2 frame2 > > So what context does make sense for symbol look ups at that point? Oh, agreed very much. I was looking up global symbols, like global constants, and in that case the block is NULL. But, I was having issues that I didn't understand using lookup_global_symbol, and lookup_symbol worked otherwise outside of the sniffer... Is the issue in the Guile bindings, that they should assume that it's sensible to get the current architecture, or the selected or current frame? > Isn't the correct answer that the sniffer should pass in an explicit > block to lookup-symbol? Yes, or in this case lookup-global-symbol. >> * You can't value-call, which is not unexpected in general, but the >> reason is unexpected: because call_function_by_hand calls >> get_current_arch and that doesn't work > > Where is that? I think you meant that the guile wrapper calls > get_current_arch, not call_function_by_hand. Yes, I see that now. I think I was confused. > Why would the unwinder want to access user / pseudo registers? > Shouldn't it be working only with raw registers? Because the user is ignorant? :) I was pleased that $pc, $sp, and $fp "worked" otherwise, so I hoped to avoid encoding architecture-specific things. Alas. (Incidentally, my patch still has the problem that passing in a pseudo register will barf.) In summary: * Is is possible to make a Maybe-style interface to sniffers, or should extension languages expose the callbacks instead because they really need to be called within their specific dynamic environments? * Regarding recursion and selected frames -- what do you think about the hack in v2 of this patch, which adds frame_unwinder_is_unwinding() ? It is a hack but it has somewhat reasonable semantics. Andy