From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75213 invoked by alias); 25 Feb 2015 18:18:10 -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 75201 invoked by uid 89); 25 Feb 2015 18:18:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,KAM_FROM_URIBL_PCCC,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-pd0-f181.google.com Received: from mail-pd0-f181.google.com (HELO mail-pd0-f181.google.com) (209.85.192.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 25 Feb 2015 18:18:08 +0000 Received: by pdev10 with SMTP id v10so6564262pde.10 for ; Wed, 25 Feb 2015 10:18:07 -0800 (PST) X-Received: by 10.66.138.109 with SMTP id qp13mr7651813pab.155.1424888286656; Wed, 25 Feb 2015 10:18:06 -0800 (PST) Received: from seba.sebabeach.org.gmail.com (173-13-178-53-sfba.hfc.comcastbusiness.net. [173.13.178.53]) by mx.google.com with ESMTPSA id i6sm42849755pdr.17.2015.02.25.10.18.05 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Feb 2015 10:18:05 -0800 (PST) From: Doug Evans To: Andy Wingo Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] JIT read_debug_info callback takes target symfile addr References: <87d250yaqq.fsf@igalia.com> Date: Wed, 25 Feb 2015 18:18:00 -0000 In-Reply-To: <87d250yaqq.fsf@igalia.com> (Andy Wingo's message of "Mon, 23 Feb 2015 15:15:57 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg00722.txt.bz2 Andy Wingo writes: > Hi, > > The attached patch makes an incompatible change to the JIT reader > interface to pass the target address of the symfile to the > read_debug_info, instead of eagerly copying the symfile to GDB and > passing the local address to the .so. In many cases this allows the > target to be simpler, as in many cases it's not necessary to allocate a > symfile object at all. In the case where you do need the memory in the > GDB address space, well the target_read() callback is there for you. > > I have a patch coming that will allow JIT readers to be implemented in > Guile. It uses the JIT reader interface, though loaded from an > extension instead of a shared library. This patch would help extensions > to be able to do JIT unwinding, as extensions have a much richer > interface to GDB and in particular can query types and sizes from the > inferior, without having to hard-code them from the reader side. What > you want is the target address, not the target's memory. > > WDYT? > > > From 983216b213af8c2cf5853a814d2559062018fce4 Mon Sep 17 00:00:00 2001 > From: Andy Wingo > Date: Mon, 23 Feb 2015 15:06:09 +0100 > Subject: [PATCH] JIT read_debug_info callback takes target symfile address > > gdb/ChangeLog: > 2015-02-23 Andy Wingo > > * NEWS: Announce JIT reader interface change. > * jit-reader.in (GDB_READER_INTERFACE_VERSION): Bump to 2. > (gdb_read_debug_info): Update typedef to express the memory as a > target address, and update the comment. > * jit.c (jit_reader_try_read_symtab): Don't read the symfile from > target memory. The JIT reader can do that if it likes using the > gdb_symbol_callbacks structure. > > gdb/testsuite/ChangeLog: > 2015-02-23 Andy Wingo > > * gdb.base/jitreader.c (read_debug_info): Update for changes in > JIT reader interface and jithost.c test. > * gdb.base/jithost.c (main): No need to allocate symfile objects > with the new GDB_READER_INTERFACE_VERSION. > * gdb.base/jithost.h: Removed. 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). 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. 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.