From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40991 invoked by alias); 20 Mar 2015 02:27:26 -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 40969 invoked by uid 89); 20 Mar 2015 02:27:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-ie0-f177.google.com Received: from mail-ie0-f177.google.com (HELO mail-ie0-f177.google.com) (209.85.223.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 20 Mar 2015 02:27:24 +0000 Received: by iecsl2 with SMTP id sl2so82029043iec.1 for ; Thu, 19 Mar 2015 19:27:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DOI7CBOYPwlWLtUELEqZDL0QsUwvYswOxA31sb1ePqI=; b=h8eAiEmX2ZdKF/XScAWVu/3T1qN6eSIRfLJ6K7hgKNulUI7sQYG9Eq8U5AR4n8En47 sxiaAQkOSQUjnjxYz8Lw+AVsglaZ2RwSw9LiFQr3sRhD3iOpxOTypqXrU0K5bDirrr7u ZWMZPYRrFDTRuCft3ujAe3iE/cLdJbAbevVlF4fFW0nxRPzaD3SX6X/9ybtBC4fju+IB WNx+/wlEwGxvrSFazQxUjbsbHFHqJwaV/LUkgKDbRjSY//gdyy/9B0YxTPx/9hviTfCU DT6Xkr0JjbdfhiZpO5pjf2pgahwBYd8nZiGHYLUYFVpJsQiJ93ooLgZzBjJQSdB4z2a9 PITA== X-Gm-Message-State: ALoCoQm0W89hkuKeXXVEM36Yn4I+X8Tb78ZsToJgjKISwWHvBDLwWpFtsT3T4IjvN/s3ySHeDoYm MIME-Version: 1.0 X-Received: by 10.50.107.7 with SMTP id gy7mr1454145igb.49.1426818442733; Thu, 19 Mar 2015 19:27:22 -0700 (PDT) Received: by 10.64.98.103 with HTTP; Thu, 19 Mar 2015 19:27:22 -0700 (PDT) In-Reply-To: <21771.26292.146330.287991@ruffy2.mtv.corp.google.com> 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 02:27:00 -0000 Message-ID: Subject: Re: [RFC] [PATCH] Provide the ability to write the frame unwinder in Python From: Alexander Smundak To: Doug Evans Cc: Andy Wingo , gdb-patches Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-03/txt/msg00614.txt.bz2 > In python, let's use EphemeralFrame instead of SnifferInfo. I'd rather have InspectedFrame than EphemeralFrame, but it's fine with me if it expedites the review. > 3) We need to allow sniffers to record anything they > want in gdb.UnwindInfo/. In Python > I'm guessing one can just add extra attributes to the > object or subclass. In Guile I guess one could use > an external container (weakly?) indexed by the > object. In both cases the documentation should > make recommendations to the reader. > [If it does and I missed it apologies.] It isn't a big issue for the JVM unwinder to do the lookups twice (first in unwinder, then in the frame filter), but it might be expensive in other languages. Not sure there is a need for multiple attributes -- wouldn't a single attribute whose value is an object suffice? > 5) The docs don't make any mention of target endianness > in the saved register values. They probably should. Register values passed are gdb.Value instances, so I thought that if they are created using the official interface (get inspected frame's register, call its `cast' method to cast it to inferior's memory pointer. then call `dereference' we wolud be fine. > 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) > but then I'm wondering if there should be an > unwind-info-set-frame-id! function and move sp,pc there. > > IOW change make-unwind-info to this so that the various > ways of creating a frame idea are don't complicate make-unwind-info. > [I realize one might want to not let make-unwind-info return > an object without a frame id, but I don't see this as a problem. > uwscm_sniffer could verify a frame id is present.] > > (let ((unwind-info (make-unwind-info ephem-frame))) > (unwind-info-set-frame-id! #:sp sp #:pc pc) > (unwind-info-add-saved-register! unwind-info "rip" rip) > ...) > > And for python: > > 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? We can (I believe penultimate patch had UnwindInfo constructor and frame_id methods). The advantage of the factory method is that it's impossible to create an UnwindInfo which lacks frame ID. > unwind_info = gdb.UnwindInfo(ephem_frame) > unwind_info.set_frame_id(...) > unwind_info.set_previous_frame_register(...) > > This could all be done in pure Python (I think), and then > pyuw_sniffer could process the object looking for expected > members(attributes) with expected types (and throw an error > if there's a problem). This way the error checking happens on return. If we have several unwinders, it will not be obvious which one sniffer the frame and returned bad UnwindInfo. > At the least let's combine unwind_info_with_id, frame_id_build_special, > and frame_id_build_wild into one function that takes keyword > arguments for each of sp, pc, special. This will loose the association with the underlying GDB API, but I am fine with this.