[RFC] Adding libbacktrace

[RFC] Adding libbacktrace

[Andrew Burgess]

Hello binutils!

I have a GDB patch series posted here:

  https://sourceware.org/pipermail/gdb-patches/2021-August/181548.html

that imports libbacktrace from the GCC repository into the
binutils-gdb repository, this would introduce a new toplevel directory
bintuils-gdb/libbacktrace/.

I don't believe that adding this module should have any significant
impact on binutils,  obviously the checkout will be slightly larger,
but libbacktrace will only be built if you're building GDB, so if
you're only building binutils there should be no build time impact.

I haven't included a patch here, as it's large, and I'm literally just
copying the code from gcc to binutils-gdb.

This email is just to make you all aware of my intentions, and, of
course, to give you a chance to make any comments (or raise any
objections) before I commit.

All feedback welcome.

Thanks,
Andrew

Re: [RFC] Adding libbacktrace

[Nick Clifton]

Hi Andrew,

> I have a GDB patch series posted here:
> that imports libbacktrace from the GCC repository into the
> binutils-gdb repository, this would introduce a new toplevel directory
> bintuils-gdb/libbacktrace/.

If you have not done so, you may also want to update the src-release.sh
script at the toplevel to add libbacktrace to the list of directories.
(See line 96).

But apart from that I have no concerns and I am happy to see the addition. :-)

Cheers
   Nick

Re: [RFC] Adding libbacktrace

[Andrew Burgess]

* Nick Clifton <nickc@redhat.com> [2021-09-01 17:11:56 +0100]:

> Hi Andrew,
> 
> > I have a GDB patch series posted here:
> > that imports libbacktrace from the GCC repository into the
> > binutils-gdb repository, this would introduce a new toplevel directory
> > bintuils-gdb/libbacktrace/.
> 
> If you have not done so, you may also want to update the src-release.sh
> script at the toplevel to add libbacktrace to the list of directories.
> (See line 96).

Hi Nick,

Good point about updating src-release.

I had a go, and ran into a few issues.  Not sure if you can offer any
advice...

So I added libbacktrace to GDB_SUPPORT_DIRS (line 330), this seems to
be how stuff like gdbsupport are handled.

However, during the call to do_proto_toplev we at one point do:

  $MAKE configure-host configure-target ....

and this results in us trying to configure a target version of
libbacktrace, which fails as there's no target compiler installed, and
indeed libbacktrace is defined as a target module (as well as a host
module).

Without any of my libbacktrace changes in place the call to
configure-target does nothing, which is slightly odd as zlib is
defined as both a host and target module too, and this is include in
the binutils-gdb repo.  However, in the generated Makefile, for some
reason that I don't understand, the rule to build zlib as a target
module has been disabled.

So, I can see two possible solutions here I think, one would be to
remove the call to configure-target from src-release.sh - surely we
don't expect to be building target libraries for binutils-gdb, right?

Or, I can try to figure out what causes the configure/build rules for
zlib (as a target module) to be disabled, and do the same thing for
libbacktrace.

Sorry if the above is a little vague, I'm not 100% sure I fully
understand everything that's going on with src-release.

Thanks,
Andrew

Re: [RFC] Adding libbacktrace

[Nick Clifton]

Hi Andrew,

> So, I can see two possible solutions here I think, one would be to
> remove the call to configure-target from src-release.sh - surely we
> don't expect to be building target libraries for binutils-gdb, right?

This script is so arcane that I would be hesitant to change anything...

> Or, I can try to figure out what causes the configure/build rules for
> zlib (as a target module) to be disabled, and do the same thing for
> libbacktrace.

My guess: zlib is in host_libs but not target_libraries, whereas libbacktrace
is in both.

Cheers
   Nick

Re: [RFC] Adding libbacktrace

[Andrew Burgess]

* Nick Clifton <nickc@redhat.com> [2021-09-10 15:34:33 +0100]:

> Hi Andrew,
> 
> > So, I can see two possible solutions here I think, one would be to
> > remove the call to configure-target from src-release.sh - surely we
> > don't expect to be building target libraries for binutils-gdb, right?
> 
> This script is so arcane that I would be hesitant to change anything...
> 
> > Or, I can try to figure out what causes the configure/build rules for
> > zlib (as a target module) to be disabled, and do the same thing for
> > libbacktrace.
> 
> My guess: zlib is in host_libs but not target_libraries, whereas libbacktrace
> is in both.

This rang a bell, so I checked, and indeed, the last time you tried to
sync the top level files from GCC to binutils-gdb the builds broke,
the reason was:

  https://sourceware.org/pipermail/binutils/2019-May/107094.html

In gcc zlib has been added to the target_libraries list.

And indeed, if I follow the same build recipe, as was reported in that
email thread, which is './configure && make all' which is different to
what I usually do, './configure && make all-{gdb,gas,bintuils,ld}'
then I see the same broken build but now with libbacktrace.

There seems to be a general problem here that our top-level Makefile
scripts will try to build target modules if they are available, even
when that's not the right thing to do for binutils-gdb.

Any ideas welcome :)

Thanks,
Andrew

Re: [RFC] Adding libbacktrace

[Nick Clifton]

Hi Andrew,

> There seems to be a general problem here that our top-level Makefile
> scripts will try to build target modules if they are available, even
> when that's not the right thing to do for binutils-gdb.
> 
> Any ideas welcome :)

Punt to gcc. :-)

More specifically, since gcc owns the so called "master" version of
the configure script, they should be the ones to fix this problem.

But I suspect that fixing this might not be at the top of their priority
list, but if you appeal to Ian Lance Taylor directly ypu may get a better
response.

Cheers
   Nick

Re: [RFC] Adding libbacktrace

[Ian Lance Taylor]

On Mon, Sep 13, 2021 at 3:46 AM Nick Clifton via Binutils
<binutils@sourceware.org> wrote:
>
> Hi Andrew,
>
> > There seems to be a general problem here that our top-level Makefile
> > scripts will try to build target modules if they are available, even
> > when that's not the right thing to do for binutils-gdb.
> >
> > Any ideas welcome :)
>
> Punt to gcc. :-)
>
> More specifically, since gcc owns the so called "master" version of
> the configure script, they should be the ones to fix this problem.
>
> But I suspect that fixing this might not be at the top of their priority
> list, but if you appeal to Ian Lance Taylor directly ypu may get a better
> response.

For GCC it's necessary for libbacktrace to be both a host module (for
use in gcc itself) and a target module (for use in libgo and
libgfortran).  For binutils/gdb, I don't see any reason for it to be a
target module.  In fact, it's not immediately obvious to me that
binutils/gdb needs any target modules at all.  So perhaps the
binutils/gdb configury should be tweaked to ignore target modules.
Maybe.

In any case I don't think there is anything to change in libbacktrace
itself, this is all a question of how the configury chooses to build
libbacktrace.

Ian

Re: [RFC] Adding libbacktrace

[Andrew Burgess]

* Ian Lance Taylor <iant@google.com> [2021-09-13 09:53:36 -0700]:

> On Mon, Sep 13, 2021 at 3:46 AM Nick Clifton via Binutils
> <binutils@sourceware.org> wrote:
> >
> > Hi Andrew,
> >
> > > There seems to be a general problem here that our top-level Makefile
> > > scripts will try to build target modules if they are available, even
> > > when that's not the right thing to do for binutils-gdb.
> > >
> > > Any ideas welcome :)
> >
> > Punt to gcc. :-)
> >
> > More specifically, since gcc owns the so called "master" version of
> > the configure script, they should be the ones to fix this problem.
> >
> > But I suspect that fixing this might not be at the top of their priority
> > list, but if you appeal to Ian Lance Taylor directly ypu may get a better
> > response.
> 
> For GCC it's necessary for libbacktrace to be both a host module (for
> use in gcc itself) and a target module (for use in libgo and
> libgfortran).  For binutils/gdb, I don't see any reason for it to be a
> target module.  In fact, it's not immediately obvious to me that
> binutils/gdb needs any target modules at all.  So perhaps the
> binutils/gdb configury should be tweaked to ignore target modules.
> Maybe.
> 
> In any case I don't think there is anything to change in libbacktrace
> itself, this is all a question of how the configury chooses to build
> libbacktrace.

Ian,

Thanks for your feedback.  I'm testing a configure.ac patch along the
lines you suggest.  I'll post it to the gcc list once I've finished
testing here.

Thanks,
Andrew