From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53041 invoked by alias); 26 Feb 2015 08:58:37 -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 53032 invoked by uid 89); 26 Feb 2015 08:58:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 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; Thu, 26 Feb 2015 08:58:34 +0000 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id BE8F03045F; Thu, 26 Feb 2015 03:58:32 -0500 (EST) Received: from pb-sasl1.int.icgroup.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id B45C63045D; Thu, 26 Feb 2015 03:58:32 -0500 (EST) 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 04DE03045C; Thu, 26 Feb 2015 03:58:31 -0500 (EST) From: Andy Wingo To: Doug Evans Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] JIT read_debug_info callback takes target symfile addr References: <87d250yaqq.fsf@igalia.com> Date: Thu, 26 Feb 2015 08:58:00 -0000 In-Reply-To: (Doug Evans's message of "Wed, 25 Feb 2015 10:17:17 -0800") Message-ID: <871tlduk0a.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: A3A89882-BD95-11E4-8C49-8FDD009B7A5A-02397024!pb-sasl1.pobox.com X-SW-Source: 2015-02/txt/msg00739.txt.bz2 Hi Doug, On Wed 25 Feb 2015 19:17, Doug Evans writes: > Hi. A couple of high level comments. > > 1) My understanding is that we still need to support older versions of > the interface, at least for awhile. > Our currently deprecation policy is to never break anything > (or something within epsilon of that). Cool. It's not a particular problem to support an older interface. > This doesn't scale. I'd like to see a formal policy where things > can live in a deprecated state for pre-specified awhile, after which > they can be deleted. ACK. > 2) It's not clear to me whether we want to continue extending the JIT > interface, or just move it to the extension languages. > We'd still keep the existing interface, deprecated. > I'm not proposing we actually do this, at least not today. Yeah, I know what you mean. After having some experience with this (https://groups.google.com/forum/#!topic/v8-users/y18bmM2I5L0) I don't think the JIT interface is really the right thing for the future. For C JIT reader extensions, you really don't have enough of an interface to do many interesting things. For extension languages, it doesn't feel quite right; you can use make-value and value-cast and all those things to turn the spare interface of the custom JIT debuginfo reader into something that feels more like the normal extension language, but you still lack a lot of information from the inferior. For example, the architecture seems to be a property of the frame, but you can't get at the current frame object from the extension. Likewise specifying registers by DWARF ID is not so nice. It would be nice if the read-register interface would return values of the proper size, as proper GDB values -- in my patch I am returning them as bytevectors because hey, registers are different sizes, but then you still don't have information on how they should be interpreted. But that's not something you want to force an extension writer to know about. The JIT interface also seems to encourage native (not cross) development, because you have little information about the target. Finally the JIT reader callbacks are awkward. I wish actually that I could unwind frames from the target without requiring the target to integrate with GDB in any way. I could do that from Guile for V8, for example, at least for the V8 part of the stack (see mail I linked above). What I would really like would be a callback to ask the Guile/Python extension "is this a frame you know about?" and then if so, let the extension unwind it. Then I wouldn't have to modify the target in any way, which would be a relief. What is the right mailing list to discuss these things? Who are the right people? I'm happy to do work off and on around these things, if you are interested. Andy