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

[Doug Evans <dje at google 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.



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.