From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31669 invoked by alias); 4 Feb 2016 18:32:41 -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 31654 invoked by uid 89); 4 Feb 2016 18:32:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=certainty, Hx-spam-relays-external:209.85.213.195, H*RU:209.85.213.195, our X-HELO: mail-ig0-f195.google.com Received: from mail-ig0-f195.google.com (HELO mail-ig0-f195.google.com) (209.85.213.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 04 Feb 2016 18:32:39 +0000 Received: by mail-ig0-f195.google.com with SMTP id mw1so4695536igb.2 for ; Thu, 04 Feb 2016 10:32:38 -0800 (PST) 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=pSH1zTBHlrwSABZ4YENdxr05C5Y8uA0BXMg2uBpopqc=; b=UrJZrDcs/P2MjaqIpG6cWRj7nMXRPSh6GsBKcFjY9OMUM2/pP8SsO7RB5ytKNDhhpf R8k7kSeC7E0KGrsi+X3fQ8eeC6GNf0rgJSi636EH0VopmJCP4EqCUEexKLmaOvWPRPha rD0/ctFy77vPwuVDMyH7GfM7ifNKzKEaGbKgn67oTkxKTQWvAmuPZ+ilIBo1VVrBefnv uGJOqCz96MzFkX5tp8T3EGV7ZRj0Oy6cq8+eAB40qtCF3YPpbZTq3CtVpcqyiEmA2/v9 AIL6RBM++CPsQcc727MH5qx3T7cA+x0AKEMB0vk7+tZMXljGyC51384a2DE5ESwu7I/S VwYg== X-Gm-Message-State: AG10YORVVAcbxI7coN2bXSsd5EeCmB0gWMgTzlNV1tKBxFzVznHrWH7kpPi6sBuCsLLXOcwscE0pJZowxdKXHA== MIME-Version: 1.0 X-Received: by 10.50.142.7 with SMTP id rs7mr5664770igb.90.1454610757231; Thu, 04 Feb 2016 10:32:37 -0800 (PST) Received: by 10.36.104.138 with HTTP; Thu, 4 Feb 2016 10:32:37 -0800 (PST) In-Reply-To: <20160204182508.289bb384@hananiah.suse.cz> 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> <20160204182508.289bb384@hananiah.suse.cz> Date: Thu, 04 Feb 2016 18:32:00 -0000 Message-ID: Subject: Re: [PATCH 2/4] Add Jeff Mahoney's py-crash patches. From: Matt Rice To: Petr Tesarik Cc: Doug Evans , Jeff Mahoney , Ales Novak , gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00129.txt.bz2 On Thu, Feb 4, 2016 at 9:25 AM, Petr Tesarik wrote: > 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. BFD has never provided releases which admit conformance to a stable API/ABI or the BFD library has always been an unstable API which you include directly and use locally in your program. Currently when a change to BFD would break some BFD using program, that program would be fixed to use the new API. Exporting BFD from gdb entails a level of certainty about how BFD may change in the future so we can keep this exported API the same in gdb as BFD changes underneath it. the closest thing I could find to this effect is from the BFD: "BFD is normally built as part of another package. See the build instructions for that package"