From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62645 invoked by alias); 20 Mar 2015 08:26:45 -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 62626 invoked by uid 89); 20 Mar 2015 08:26:42 -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; Fri, 20 Mar 2015 08:26:40 +0000 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id E9E52408BC; Fri, 20 Mar 2015 04:26:37 -0400 (EDT) Received: from pb-sasl1.int.icgroup.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id E3352408BA; Fri, 20 Mar 2015 04:26:37 -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 185FB408B9; Fri, 20 Mar 2015 04:26:36 -0400 (EDT) From: Andy Wingo To: Doug Evans Cc: Alexander Smundak , gdb-patches Subject: Re: [RFC] [PATCH] Provide the ability to write the frame unwinder in Python References: <21714.40641.510825.30998@ruffy2.mtv.corp.google.com> <54E71694.1080304@redhat.com> <87ioei31uj.fsf@igalia.com> <87d24p19tt.fsf@igalia.com> <54FD7DAA.7010603@redhat.com> <87twxrncld.fsf@igalia.com> <87ioe1dvu2.fsf@igalia.com> <87sid4atms.fsf@igalia.com> <87fv918kyf.fsf@igalia.com> <21771.26292.146330.287991@ruffy2.mtv.corp.google.com> Date: Fri, 20 Mar 2015 08:26:00 -0000 In-Reply-To: <21771.26292.146330.287991@ruffy2.mtv.corp.google.com> (Doug Evans's message of "Thu, 19 Mar 2015 17:15:48 -0700") Message-ID: <87619w6pmt.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: D35DF652-CEDA-11E4-B65E-EA766A2A9587-02397024!pb-sasl1.pobox.com X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg00621.txt.bz2 Hi, Thanks for taking the time to look at the patches, Doug! On Fri 20 Mar 2015 01:15, Doug Evans writes: > 2) IIUC, setting aside hitting the outermost frame and such, > it's a rule that some unwinder will recognize the frame. > Therefore "ephemeral" isn't quite right, even "real" > frames are ephemeral since we toss the frame cache when > the inferior resumes. OTOH, we need to make progress > and I'm just throwing this out there. "ephemeral" is > fine with me: we don't use that term for anything else > which is nice. Just to throw out some other names -- PendingFrame. Alexander mentioned InspectedFrame. IntermediateFrame. FrameTemplate. SkeletonFrame. MinimalFrame. FrameStub. Dunno, just some ideas :) > 3) We need to allow sniffers to record anything they > want in gdb.UnwindInfo/. I see from your point (4) later that you are thinking that if we add some kind of callback interface to UnwindInfo that e.g. Guile code might need to fetch arbitrary data from the UnwindInfo. You also note correctly that this is not currently something that the patches require -- the UnwindInfo contains all of the information, and the C prev_register/this_id callbacks just look into the UnwindInfo data. If we did add a callback interface I don't think there would be a problem. Let's say we want to add a way for prev_register to call back into Guile. If the prev-register callback is added to the unwind info via unwind-info-set-prev-register-callback! or something then the callback can be a closure that captures the data it needs. Or it can use an external weak hash table. Or when we add the set-prev-register-callback! interface, we can add some other associated interface to store data in the unwind-info. There are multiple fine options here. > 5) The docs don't make any mention of target endianness > in the saved register values. They probably should. +1 to Alexander's answer -- as they are GDB values, there shouldn't be an issue, should there? > 6) I noticed several routines for building frame ids in Python. > Both Python and Guile support keyword based arguments to functions. > Can we just have one frame id builder function and each take > sp and pc (and special if we need to) as keyword arguments? > E.g. (make-unwind-info ephem-frame #:sp sp #:pc pc) > But see (7) below. > > 7) If we ever need to use frame ids in the extension language > IWBN if they were their own object, in which case we might have > (make-unwind-info ephem-frame #:frame-id frame-id) This would be fine; and actually at this point the kwarg is unnecessary. (make-unwind-info ephem-frame frame-id) > but then I'm wondering if there should be an > unwind-info-set-frame-id! function and move sp,pc there. I agree with Alexander that this isn't great. The only thing that an unwinder *must* do is set a frame ID. It must produce a frame_id at the same time as the sniffer returns TRUE. (They are different callbacks but always called one after the other.) Therefore it makes sense to have the invariant: Is it an UnwindInfo? Then it definitely has a frame ID. That way it takes away one possible error case. Also you wouldn't want to set the frame ID on an UnwindInfo twice, it doesn't make sense. > I'm not sure where to put the UnwindInfo creator (factory method). > Do we need one? Can we just create them via normal object construction? In Guile you have to give it a name of course -- make-unwind-info. But in Python I liked Alexander's use of a factory method. But I dunno, I'll leave the Python discussion to you all :) > 8) Re: set_previous_frame_register vs unwind-info-add-saved-register! > > Dunno. On this particular point I guess I don't have a strong > enough interesting in being consistent. > I'll let you guys decide. If you don't have such an interest on being consistent for this piece then I guess the easy way is to leave these as they are then. Avoids multiple-day awkward backs and forths :) But if you decide they need to be the same let us know. Speaking for myself I prefer the Guile one of course, but I prefer executive decisions over having to endure more days of naming discussions over email :) Thank you again Doug for the time! Andy