From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53338 invoked by alias); 3 Feb 2016 18:31:04 -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 53323 invoked by uid 89); 3 Feb 2016 18:31:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2219, convincing, sk:python-, our X-HELO: mail-vk0-f53.google.com Received: from mail-vk0-f53.google.com (HELO mail-vk0-f53.google.com) (209.85.213.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 03 Feb 2016 18:31:02 +0000 Received: by mail-vk0-f53.google.com with SMTP id e185so20660012vkb.1 for ; Wed, 03 Feb 2016 10:31:02 -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:from:date :message-id:subject:to:cc:content-type; bh=op/NwrS08LnA814p/oL89xdl3553WkMl22hRxWPp/04=; b=LYgEEhjm/nk6A7Q/6KOeLSYa0/0nL8/EdfBP6obYJYa3n3ElWJVMfaCSbX3hr5M8r/ HB9LWwIllbuwiNbbxVK4q7Fx94Pet3tszkPpu51nQdsgjhaAJjUMA5eNRMerR6l3jA+D hvQSIjEc1k4z9A/CB2tqHx4EewSEB3/rFHDYhdXMhcwTCtv4zQKyuxNOK8JL3d59gRzx PTitvGWBIUUdQtW0fQYWka2yQbkgwgE89MwiHOktojK5H2BD1oALMxdX2SCpAKqazPog 4M03M1KJGWCt3yGIBwQP8hcNx65UMd7Oq5e8Xoj7jGw/zUjStGPMoCr9O/z1T1rWrkBL Y/0w== X-Gm-Message-State: AG10YOQODja2KzUjnI2e3nT8JBaYC8Cxflle+gvJUOiHy4On/7BeJ8AErsOEVusnjhosmno/ncwJ44clGnrvjyMj X-Received: by 10.31.15.4 with SMTP id 4mr2019569vkp.10.1454524260159; Wed, 03 Feb 2016 10:31:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.148.216 with HTTP; Wed, 3 Feb 2016 10:30:20 -0800 (PST) In-Reply-To: <56B23F1A.20408@suse.com> 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> From: Doug Evans Date: Wed, 03 Feb 2016 18:31:00 -0000 Message-ID: Subject: Re: [PATCH 2/4] Add Jeff Mahoney's py-crash patches. To: Jeff Mahoney Cc: Ales Novak , gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00094.txt.bz2 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. I'm certainly open to others convincing me I'm wrong. But that is my understanding. What we can do is export ELF, and that is what I'd like to see.