Re: [PATCH 2/4] Add Jeff Mahoney's py-crash patches.

[Matt Rice <ratmice at gmail dot com>]

On Thu, Feb 4, 2016 at 9:25 AM, Petr Tesarik <ptesarik@suse.cz> wrote:
> Hi Doug,
>
> On Wed, 3 Feb 2016 10:30:20 -0800
> Doug Evans <dje@google.com> wrote:
>
>> On Wed, Feb 3, 2016 at 9:55 AM, Jeff Mahoney <jeffm@suse.com> 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"