From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39685 invoked by alias); 4 Feb 2016 22:27:34 -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 39667 invoked by uid 89); 4 Feb 2016 22:27:34 -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=publishing, carving X-HELO: mail-vk0-f50.google.com Received: from mail-vk0-f50.google.com (HELO mail-vk0-f50.google.com) (209.85.213.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 04 Feb 2016 22:27:29 +0000 Received: by mail-vk0-f50.google.com with SMTP id e64so46303995vkg.0 for ; Thu, 04 Feb 2016 14:27:28 -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=F7RwV6W2984SyfXjs1MfDidbIQme8ITSIiRl7dWtY/0=; b=C97LQ3350Jh2SRtVBLiS0lrzZ1/DDVB5hIWrYmxCyD5Qp5GJ4pL5a2I6tFyGthUuUy DCRLW0qni5V9qsvC+ZiKD0m9zmHnIOs19V4U6Xy1xZIRTajDBBG6y7W1flu4pdl++F7L u/gfTVPCOzJjlYGBl88NUbEhzyI3Q8EohEiLykrxMVNKB64R5ulXwpUDfMl1Jpreww+5 V2ew/Lw5Uh92sX5Dze4fvSeufM77GZKlSX1t6HLt22YGbbRqPri445JZ9JyG8HIXh/AY i1xw85LK/wkg0aA5loAln4CbQsT51qbwsvoUNq5aa23sSHva578mDcgYn7bXh5JI2sa/ ED8Q== X-Gm-Message-State: AG10YOTuv9tLHhrv9+fEXC93xn/B/SnVzKNuTtlXeyZRksjwPBL5Gn5LVbomJXB09Kf17w/A7Oz3OtAHeKHyxFjf X-Received: by 10.31.6.143 with SMTP id 137mr7125802vkg.133.1454624846509; Thu, 04 Feb 2016 14:27:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.148.216 with HTTP; Thu, 4 Feb 2016 14:26:46 -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> From: Doug Evans Date: Thu, 04 Feb 2016 22:27:00 -0000 Message-ID: Subject: Re: [PATCH 2/4] Add Jeff Mahoney's py-crash patches. To: Petr Tesarik Cc: Jeff Mahoney , Ales Novak , gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00132.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. Hi. I'm not sure this is written down anywhere, but the basic answer is that bfd is explicitly not a published API. The developers reserve the right to rewrite it at will. [Not that any kind of "rewrite" will ever happen, but things do get changed.] Exporting it to python means such changes are harder, if not impossible, to make. Which isn't to say that the gnu tools shouldn't be providing published APIs for such things. I think they should. But bfd has a lot of, ummm, history, and publishing it as a stable API is unlikely to get buy-in from anyone. I could be wrong of course. Maybe someone could start carving off bits of it to publish, but I would go slow and get consensus before proceeding too far - I wouldn't want anyone to end up wasting time on this.