From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26361 invoked by alias); 3 Feb 2016 19:29:48 -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 26339 invoked by uid 89); 3 Feb 2016 19:29:48 -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=our 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; Wed, 03 Feb 2016 19:29:46 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 89FABAAC4; Wed, 3 Feb 2016 19:29:43 +0000 (UTC) Subject: Re: [PATCH 2/4] Add Jeff Mahoney's py-crash patches. To: Doug Evans 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> Cc: Ales Novak , gdb-patches From: Jeff Mahoney X-Enigmail-Draft-Status: N1110 Message-ID: <56B25525.1000708@suse.com> Date: Wed, 03 Feb 2016 19:29:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00099.txt.bz2 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/3/16 1:30 PM, 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. > > 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. Ok, so looking at this again, I don't need full section information. I just need a name. Would it be acceptable to just export the name of the section via gdb.Symbol and my new gdb.MinSymbol instead? - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJWslUlAAoJEB57S2MheeWy2KYP/0t+pzbrp9blhgMF2JBKkqhD ZM+RbVZFaQysJdINqeTZcF9lYkg7f0eJ0Xi6+3/6+zniTDAKtvxIHlgq15cO1itM XrUAArhedT684Klm80BL8PUp10pamTyFO34p4EdKVeWajWXIt8UWxo+wQv9nvldA J163npwniBYk7ZsoNz13RvtRLyL1BOQEhh/xoODAs8SJGm8MRpydLw4QNRN+KTb5 NkSCXuh0cORz0/KN6yugsR4SZ/JnBovm0iIQu47IiZbVG0SbQk5thtF002ejojL4 O5KOSQxW5wfcWNbBo79bw45+S+MPBpEZItPXaXeiFZBBL7agYEmCO50+iKv93xLw 0f1MPA6GuJjM3yLld+ONPFnrC3Mw/CVPBkuxUgVwQedzGUkRJ7zzGVvGbnSmzvyI YIVXea4u4YG4Lk/d0+XTozfNfrm5kRfvtVckX3ThVMDyKIacJyVLGGKDHV5UvRlh oUOPUeiwaOyPqY46gyNepuY7tebg10ykeso5TpMqrJVwUfL0Ri4jIKKVSYvvvG7U 9M748VB/an1idysIZ9z1D7gIbs11L+jeq44Hy2AJe0nfVdsJKXy6NjCKrW1vXlKA X5gP85oPe89iACtRE3TlBbl916dsW67GHP6oUvCpKseliqsevRuUsC8/gukpFOpe e6V1i8k5z+2doLxHv7by =b8yC -----END PGP SIGNATURE-----