From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129180 invoked by alias); 4 Feb 2016 17:25:15 -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 129165 invoked by uid 89); 4 Feb 2016 17:25:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2446, H*MI:sk:56B23F1, our, sk:python- X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Thu, 04 Feb 2016 17:25:13 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 305C8AC01; Thu, 4 Feb 2016 17:25:10 +0000 (UTC) Date: Thu, 04 Feb 2016 17:25:00 -0000 From: Petr Tesarik To: Doug Evans Cc: Jeff Mahoney , Ales Novak , gdb-patches Subject: Re: [PATCH 2/4] Add Jeff Mahoney's py-crash patches. Message-ID: <20160204182508.289bb384@hananiah.suse.cz> In-Reply-To: References: <1454276692-7119-1-git-send-email-alnovak@suse.cz> <1454276692-7119-3-git-send-email-alnovak@suse.cz> <56B01AB9.90005@suse.com> <56B23F1A.20408@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00118.txt.bz2 Hi Doug, On Wed, 3 Feb 2016 10:30:20 -0800 Doug Evans wrote: > On Wed, Feb 3, 2016 at 9:55 AM, Jeff Mahoney wrote: > >... > >>> Hi. > >> > >> Hi Doug - > >> > >>> Part of what this patch is doing is exporting bfd to python. > >>> E.g., all the SEC_* constants. > >> > >>> As a rule we absolutely discourage people from using bfd outside > >>> of the the binutils+gdb source tree. Either this rule needs to > >>> change, or I don't think we can allow this patch. I'd be > >>> interested to hear what others in the community think. > >> > >> That's unfortunate. The Linux kernel uses ELF sections for a > >> number of purposes. Most notably is the definition of per-cpu > >> variables. Without the ELF section, we can't resolve the addresses > >> for the variables. So, from our perspective, it's a requirement. > >> > >>> For myself, I would much rather export ELF separately (e.g., a > >>> separate python API one can use independent of any particular > >>> tool, including gdb), and then have gdb provide the necessary > >>> glue to use this API. [I can imagine some compromises being > >>> needed, at least for now; e.g., it'd be cumbersome to read in all > >>> ELF symbols twice. But fixing that is just an optimization.] > >> > >> Ok, that's doable. As it is, the section code mixes GDB and BFD > >> pretty heavily. It shouldn't be too difficult to separate the two > >> out and push the section stuff into a new BFD python interface and > >> associate the objfiles with it. > > > > And here's what I've come up with. Does this constitute enough of a > > separation? It /should/ cross over into the BFD code in the same way > > that the GDB code does: As soon as we hit a bfd object or a > > bfd_section object, we call into bfd's new python API to generate the > > objects. > > > > https://jeffm.io/git/cgit.cgi/gnu/binutils-gdb/log/?h=gdb/python-bfd > > > > For the fully-integrated kdump work, use the python-bfd-kdump branch > > (or SUSE folks, python-bfd-kdump-buildid will pick up the separate > > debuginfos as we usually expect). > > Separation isn't the issue, unfortunately. > The issue is that we cannot export bfd to python, period. Excuse my ignorance, but can you explain a bit more why BFD should not be used? I'm sure there has been some discussion on that topic; a pointer in the right direction would be welcome. TIA, Petr Tesarik