This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 2/4] Add Jeff Mahoney's py-crash patches.
- From: Petr Tesarik <ptesarik at suse dot cz>
- To: Doug Evans <dje at google dot com>
- Cc: Jeff Mahoney <jeffm at suse dot com>, Ales Novak <alnovak at suse dot cz>, gdb-patches <gdb-patches at sourceware dot org>
- Date: Thu, 4 Feb 2016 18:25:08 +0100
- Subject: Re: [PATCH 2/4] Add Jeff Mahoney's py-crash patches.
- Authentication-results: sourceware.org; auth=none
- References: <1454276692-7119-1-git-send-email-alnovak at suse dot cz> <1454276692-7119-3-git-send-email-alnovak at suse dot cz> <CADPb22TwarW84NbuqczsjFFq5DPEEMVuyHjtFHGU4LVBjj6wGQ at mail dot gmail dot com> <56B01AB9 dot 90005 at suse dot com> <56B23F1A dot 20408 at suse dot com> <CADPb22Q2G2_2LVGfkzLtj-445zR3TZKgLw-XsQPbdfoF2Z2bSg at mail dot gmail dot com>
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.
TIA,
Petr Tesarik