gdb: link executables with libtool
Commit Message
This patch changes the GDB build system in order to use libtool to
link the several built executables. This makes it possible to refer
to libtool libraries (.la files) in CLIBS.
As an application of the above,
LIBBACKTRACE_LIB now refers to ../libbacktrace/libbacktrace.la
LIBCTF now refers to ../libctf/libctf.la
NOTE1: The addition of libtool adds a few new configure-time options
to GDB. Among these, --enable-shared and --disable-shared, which were
previously ignored. Now GDB shall honor these options when linking,
picking up the right version of the referred libtool libraries
automagically.
These tests seems to be sensible to the fact there is now a new
process in the mixture (the sh process.) This is why the patch
modifies testsuite/lib/gdb.exp in order to run the tests thru libtool
--mode=execute. Doing so avoids the regressions.
NOTE2: I have not tested the insight build.
NOTE3: For regenerating configure I used an environment with Autoconf
2.69 and Automake 1.15.1. This should match the previously
used version as announced in the configure script. I am not
including the thunk for configure in this patch because the
libtool macros drag in a lot of stuff and the resulting patch
is very big.
Testing performed:
- --enable-shared and --disable-shared (the default in binutils) work
as expected: the linked executables link with the archive or shared
libraries transparently.
- Makefile.in modified for EXEEXT = .exe. It installs the binaries
just fine. The installed gdb.exe runs fine.
- Native build regtested in x86_64. The installed gdb runs fine.
In the regression testing I'm observing that the following tests
doesn't seem to be deterministic:
gdb.base/step-over-syscall.exp
gdb.threads/process-dies-while-detaching.exp
gdb.threads/process-dies-while-handling-bp.exp
Sometimes some of the the tests in these files unexpectedly fail,
like in:
-PASS: gdb.threads/process-dies-while-detaching.exp: single-process: \
continue: detach: continue
+FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: \
continue: detach: continue
Sometimes they unexpectedly pass:
-KFAIL: gdb.base/step-over-syscall.exp: clone: displaced=on: \
check_pc_after_cross_syscall: single step over clone \
final pc (PRMS: gdb/19675)
+PASS: gdb.base/step-over-syscall.exp: clone: displaced=on: \
check_pc_after_cross_syscall: single step over clone final pc
-KFAIL: gdb.threads/process-dies-while-handling-bp.exp: \
non_stop=on: cond_bp_target=0: inferior 1 exited \
(prompt) (PRMS: gdb/18749)
+PASS: gdb.threads/process-dies-while-handling-bp.exp: \
non_stop=on: cond_bp_target=0: inferior 1 exited
- Cross build for aarch64-linux-gnu built to exercise
program_transform_name and friends. The installed
aarch64-linux-gnu-gdb runs fine.
2022-11-05 Jose E. Marchesi <jose.marchesi@oracle.com>
* gdb/aclocal.m4: include libtool macros from the top-level
directory.
* gdb/Makefile.in (LIBTOOL): Define.
(CC_LD): Use libtool for linking.
(install-only): Use libtool for installing GDB$(EXEEXT).
(install-gdbtk): Likewise for insight$(EXEEXT).
* gdb/configure.ac: Call LT_INIT.
Refer to libctf.la and libbacktrace.la.
* gdb/configure: Regenerate.
* gdb/testsuite/lib/gdb.exp: Run uninstalled GDB with libtool
--mode=execute.
---
ChangeLog | 14 +
gdb/Makefile.in | 10 +-
gdb/aclocal.m4 | 5 +
gdb/configure | 31544 ++++++++++++++++++++++++------------
gdb/configure.ac | 15 +-
gdb/testsuite/lib/gdb.exp | 2 +-
6 files changed, 21140 insertions(+), 10450 deletions(-)
Comments
> Date: Sat, 5 Nov 2022 14:08:27 +0100
> From: "Jose E. Marchesi via Gdb-patches" <gdb-patches@sourceware.org>
> Cc: indu.bhagat@oracle.com, elena.zannoni@oracle.com
>
> This patch changes the GDB build system in order to use libtool to
> link the several built executables. This makes it possible to refer
> to libtool libraries (.la files) in CLIBS.
If this is supposed to be installed before we start the release cycle
of GDB 13, I question the wisdom of making such a significant change
when we are so close to the next release.
Does this solve some grave problems, or can we wait until after GDB
13?
>> Date: Sat, 5 Nov 2022 14:08:27 +0100
>> From: "Jose E. Marchesi via Gdb-patches" <gdb-patches@sourceware.org>
>> Cc: indu.bhagat@oracle.com, elena.zannoni@oracle.com
>>
>> This patch changes the GDB build system in order to use libtool to
>> link the several built executables. This makes it possible to refer
>> to libtool libraries (.la files) in CLIBS.
>
> If this is supposed to be installed before we start the release cycle
> of GDB 13, I question the wisdom of making such a significant change
> when we are so close to the next release.
>
> Does this solve some grave problems, or can we wait until after GDB
> 13?
Basically it would unstuck us in getting the SFrame integration applied
in binutils.
See
https://sourceware.org/pipermail/gdb-patches/2022-November/193381.html
We could go with the simpler solution suggested in that email (already
used by libbacktrace and libctf) in GDB 13 and then we can apply the new
patch to switch to libtool for linking.
I know Mike doesn't like the idea; but I hope we have proved we do our
homework?
On 11/5/22 10:30, Jose E. Marchesi via Gdb-patches wrote:
>
>>> Date: Sat, 5 Nov 2022 14:08:27 +0100
>>> From: "Jose E. Marchesi via Gdb-patches" <gdb-patches@sourceware.org>
>>> Cc: indu.bhagat@oracle.com, elena.zannoni@oracle.com
>>>
>>> This patch changes the GDB build system in order to use libtool to
>>> link the several built executables. This makes it possible to refer
>>> to libtool libraries (.la files) in CLIBS.
>>
>> If this is supposed to be installed before we start the release cycle
>> of GDB 13, I question the wisdom of making such a significant change
>> when we are so close to the next release.
>>
>> Does this solve some grave problems, or can we wait until after GDB
>> 13?
>
> Basically it would unstuck us in getting the SFrame integration applied
> in binutils.
>
> See
> https://sourceware.org/pipermail/gdb-patches/2022-November/193381.html
>
> We could go with the simpler solution suggested in that email (already
> used by libbacktrace and libctf) in GDB 13 and then we can apply the new
> patch to switch to libtool for linking.
>
> I know Mike doesn't like the idea; but I hope we have proved we do our
> homework?
IIUC, it would not be useful to have the libtool changes without the
SFrame changes. And given that the GDB 13 branch is supposed to be cut
very shortly, do we expect to have the SFrame changes in GDB 13 (I have
no idea what that consists of)? If not, then the libtool changes are
not really needed in GDB 13.
Simon
> On 11/5/22 10:30, Jose E. Marchesi via Gdb-patches wrote:
>>
>>>> Date: Sat, 5 Nov 2022 14:08:27 +0100
>>>> From: "Jose E. Marchesi via Gdb-patches" <gdb-patches@sourceware.org>
>>>> Cc: indu.bhagat@oracle.com, elena.zannoni@oracle.com
>>>>
>>>> This patch changes the GDB build system in order to use libtool to
>>>> link the several built executables. This makes it possible to refer
>>>> to libtool libraries (.la files) in CLIBS.
>>>
>>> If this is supposed to be installed before we start the release cycle
>>> of GDB 13, I question the wisdom of making such a significant change
>>> when we are so close to the next release.
>>>
>>> Does this solve some grave problems, or can we wait until after GDB
>>> 13?
>>
>> Basically it would unstuck us in getting the SFrame integration applied
>> in binutils.
>>
>> See
>> https://sourceware.org/pipermail/gdb-patches/2022-November/193381.html
>>
>> We could go with the simpler solution suggested in that email (already
>> used by libbacktrace and libctf) in GDB 13 and then we can apply the new
>> patch to switch to libtool for linking.
>>
>> I know Mike doesn't like the idea; but I hope we have proved we do our
>> homework?
>
> IIUC, it would not be useful to have the libtool changes without the
> SFrame changes. And given that the GDB 13 branch is supposed to be cut
> very shortly, do we expect to have the SFrame changes in GDB 13 (I have
> no idea what that consists of)? If not, then the libtool changes are
> not really needed in GDB 13.
The SFrame support (it is a frame unwinding format) is purely in
binutils (assembler, and linker via BFD) and, per-se, it doesn't concern
GDB at all.
The issue is that given the current way GDB links with BFD (directly
with the ../bfd/libbfd.a archive) it becomes necessary to also
explicitly list libbfd's dependencies in the GDB build system. In the
binutils SFrame patch we are introducing a libsframe in binutils, and
make libbfd link with it. Having to satify these kind of indirect
dependencies for in-tree libraries in the GDB build system is generally
not a good idea, and therefore Mike's suggestion on making GDB use
libtool for linking and the patch I sent.
The patch also eliminates GDB's reliance on libtool internal paths like
.libs/foo.so (alghough doing that it is something not unheard of ^^.)
When is GDB 13 expected to be branched?
On 11/5/22 14:04, Jose E. Marchesi wrote:
>
>> On 11/5/22 10:30, Jose E. Marchesi via Gdb-patches wrote:
>>>
>>>>> Date: Sat, 5 Nov 2022 14:08:27 +0100
>>>>> From: "Jose E. Marchesi via Gdb-patches" <gdb-patches@sourceware.org>
>>>>> Cc: indu.bhagat@oracle.com, elena.zannoni@oracle.com
>>>>>
>>>>> This patch changes the GDB build system in order to use libtool to
>>>>> link the several built executables. This makes it possible to refer
>>>>> to libtool libraries (.la files) in CLIBS.
>>>>
>>>> If this is supposed to be installed before we start the release cycle
>>>> of GDB 13, I question the wisdom of making such a significant change
>>>> when we are so close to the next release.
>>>>
>>>> Does this solve some grave problems, or can we wait until after GDB
>>>> 13?
>>>
>>> Basically it would unstuck us in getting the SFrame integration applied
>>> in binutils.
>>>
>>> See
>>> https://sourceware.org/pipermail/gdb-patches/2022-November/193381.html
>>>
>>> We could go with the simpler solution suggested in that email (already
>>> used by libbacktrace and libctf) in GDB 13 and then we can apply the new
>>> patch to switch to libtool for linking.
>>>
>>> I know Mike doesn't like the idea; but I hope we have proved we do our
>>> homework?
>>
>> IIUC, it would not be useful to have the libtool changes without the
>> SFrame changes. And given that the GDB 13 branch is supposed to be cut
>> very shortly, do we expect to have the SFrame changes in GDB 13 (I have
>> no idea what that consists of)? If not, then the libtool changes are
>> not really needed in GDB 13.
>
> The SFrame support (it is a frame unwinding format) is purely in
> binutils (assembler, and linker via BFD) and, per-se, it doesn't concern
> GDB at all.
>
> The issue is that given the current way GDB links with BFD (directly
> with the ../bfd/libbfd.a archive) it becomes necessary to also
> explicitly list libbfd's dependencies in the GDB build system. In the
> binutils SFrame patch we are introducing a libsframe in binutils, and
> make libbfd link with it. Having to satify these kind of indirect
> dependencies for in-tree libraries in the GDB build system is generally
> not a good idea, and therefore Mike's suggestion on making GDB use
> libtool for linking and the patch I sent.
Thanks for the explanation.
> The patch also eliminates GDB's reliance on libtool internal paths like
> .libs/foo.so (alghough doing that it is something not unheard of ^^.)
>
> When is GDB 13 expected to be branched?
I don't know, it's up to Joel. The latest update is:
https://inbox.sourceware.org/gdb-patches/Y2K24aU9cNVXo0hC@adacore.com/T/#mfaac801866d08eedcd94b5ce85257389bdecfec6
Personally, I would not be too worried to see this change in GDB 13, but
others (like Eli) may think differently.
Simon
On 05 Nov 2022 19:04, Jose E. Marchesi via Gdb-patches wrote:
> > On 11/5/22 10:30, Jose E. Marchesi via Gdb-patches wrote:
> >>>> Date: Sat, 5 Nov 2022 14:08:27 +0100
> >>>> From: "Jose E. Marchesi via Gdb-patches" <gdb-patches@sourceware.org>
> >>>> Cc: indu.bhagat@oracle.com, elena.zannoni@oracle.com
> >>>>
> >>>> This patch changes the GDB build system in order to use libtool to
> >>>> link the several built executables. This makes it possible to refer
> >>>> to libtool libraries (.la files) in CLIBS.
> >>>
> >>> If this is supposed to be installed before we start the release cycle
> >>> of GDB 13, I question the wisdom of making such a significant change
> >>> when we are so close to the next release.
> >>>
> >>> Does this solve some grave problems, or can we wait until after GDB
> >>> 13?
> >>
> >> Basically it would unstuck us in getting the SFrame integration applied
> >> in binutils.
> >>
> >> See
> >> https://sourceware.org/pipermail/gdb-patches/2022-November/193381.html
> >>
> >> We could go with the simpler solution suggested in that email (already
> >> used by libbacktrace and libctf) in GDB 13 and then we can apply the new
> >> patch to switch to libtool for linking.
> >>
> >> I know Mike doesn't like the idea; but I hope we have proved we do our
> >> homework?
> >
> > IIUC, it would not be useful to have the libtool changes without the
> > SFrame changes. And given that the GDB 13 branch is supposed to be cut
> > very shortly, do we expect to have the SFrame changes in GDB 13 (I have
> > no idea what that consists of)? If not, then the libtool changes are
> > not really needed in GDB 13.
>
> The SFrame support (it is a frame unwinding format) is purely in
> binutils (assembler, and linker via BFD) and, per-se, it doesn't concern
> GDB at all.
is it really a big deal to wait for the GDB 13 branch to be cut ? with
binutils-2.39 being recentlyish released, it's not like binutils-2.40 is
coming out any time soon. further, afaict, the sframe patchset hasn't
finished review even on the binutils side.
-mike
On 11/5/22 19:46, Mike Frysinger wrote:
> coming out any time soon. further, afaict, the sframe patchset hasn't
> finished review even on the binutils side.
SFrame patch set has had an interesting ride. The version V2 was
earlier reviewed and approved
https://sourceware.org/pipermail/binutils/2022-October/123810.html. I
posted a V3 because I made a bugfix and an additional diff was
identified for sim/ buildsystem.
Once we have more clarity on how we want to proceed with the gdb/ bits,
I can update the series and proceed with the next steps.
> Date: Sun, 6 Nov 2022 09:46:50 +0700
> From: Mike Frysinger via Gdb-patches <gdb-patches@sourceware.org>
> Cc: Simon Marchi <simark@simark.ca>, indu.bhagat@oracle.com,
> gdb-patches@sourceware.org, elena.zannoni@oracle.com
>
> > The SFrame support (it is a frame unwinding format) is purely in
> > binutils (assembler, and linker via BFD) and, per-se, it doesn't concern
> > GDB at all.
>
> is it really a big deal to wait for the GDB 13 branch to be cut ? with
> binutils-2.39 being recentlyish released, it's not like binutils-2.40 is
> coming out any time soon. further, afaict, the sframe patchset hasn't
> finished review even on the binutils side.
Based on history, I'd expect Binutils 2.40 around February.
@@ -1,3 +1,17 @@
+2022-11-05 Jose E. Marchesi <jose.marchesi@oracle.com>
+
+ * gdb/aclocal.m4: include libtool macros from the top-level
+ directory.
+ * gdb/Makefile.in (LIBTOOL): Define.
+ (CC_LD): Use libtool for linking.
+ (install-only): Use libtool for installing GDB$(EXEEXT).
+ (install-gdbtk): Likewise for insight$(EXEEXT).
+ * gdb/configure.ac: Call LT_INIT.
+ Refer to libctf.la and libbacktrace.la.
+ * gdb/configure: Regenerate.
+ * gdb/testsuite/lib/gdb.exp: Run uninstalled GDB with libtool
+ --mode=execute.
+
2022-10-10 Nick Clifton <nickc@redhat.com>
* src-release.sh: Add "-r <date>" option to create reproducible
@@ -143,10 +143,12 @@ MAKEINFO_CMD = $(MAKEINFO) $(MAKEINFOFLAGS) $(MAKEINFO_EXTRA_FLAGS)
MAKEHTML = $(MAKEINFO_CMD) --html
MAKEHTMLFLAGS =
+LIBTOOL = @LIBTOOL@
+
# Set this up with gcc if you have gnu ld and the loader will print out
# line numbers for undefined references.
#CC_LD = g++ -static
-CC_LD = $(CXX) $(CXX_DIALECT)
+CC_LD = $(LIBTOOL) --mode=link $(CXX) $(CXX_DIALECT)
# Where is our "include" directory? Typically $(srcdir)/../include.
# This is essentially the header file directory for the library
@@ -2017,7 +2019,8 @@ install-only: $(CONFIG_INSTALL)
true ; \
fi ; \
$(SHELL) $(srcdir)/../mkinstalldirs $(DESTDIR)$(bindir) ; \
- $(INSTALL_PROGRAM_ENV) $(INSTALL_PROGRAM) gdb$(EXEEXT) \
+ $(LIBTOOL) --mode=install $(INSTALL_PROGRAM_ENV) $(INSTALL_PROGRAM) \
+ gdb$(EXEEXT) \
$(DESTDIR)$(bindir)/$$transformed_name$(EXEEXT) ; \
$(SHELL) $(srcdir)/../mkinstalldirs $(DESTDIR)$(includedir)/gdb ; \
$(INSTALL_DATA) jit-reader.h $(DESTDIR)$(includedir)/gdb/jit-reader.h
@@ -2529,7 +2532,8 @@ install-gdbtk:
true ; \
fi ; \
$(SHELL) $(srcdir)/../mkinstalldirs $(DESTDIR)$(bindir); \
- $(INSTALL_PROGRAM_ENV) $(INSTALL_PROGRAM) insight$(EXEEXT) \
+ $(LIBTOOL) --mode=install $(INSTALL_PROGRAM_ENV) $(INSTALL_PROGRAM) \
+ insight$(EXEEXT) \
$(DESTDIR)$(bindir)/$$transformed_name$(EXEEXT) ; \
$(SHELL) $(srcdir)/../mkinstalldirs \
$(DESTDIR)$(GDBTK_LIBRARY) ; \
@@ -212,4 +212,9 @@ m4_include([../config/override.m4])
m4_include([../config/pkg.m4])
m4_include([../config/plugins.m4])
m4_include([../config/tcl.m4])
+m4_include([../libtool.m4])
+m4_include([../ltoptions.m4])
+m4_include([../ltsugar.m4])
+m4_include([../ltversion.m4])
+m4_include([../lt~obsolete.m4])
m4_include([acinclude.m4])
@@ -46,6 +46,10 @@ ACX_NONCANONICAL_TARGET
AC_ARG_PROGRAM
+# We require libtool to link with the in-tree libtool libraries
+# the proper way.
+LT_INIT
+
# We require a C++11 compiler. Check if one is available, and if
# necessary, set CXX_DIALECT to some -std=xxx switch.
AX_CXX_COMPILE_STDCXX(11, , mandatory)
@@ -2092,7 +2096,7 @@ AC_ARG_ENABLE([libbacktrace],
if test "${enable_libbacktrace}" = "yes"; then
LIBBACKTRACE_INC="-I$srcdir/../libbacktrace/ -I../libbacktrace/"
- LIBBACKTRACE_LIB=../libbacktrace/.libs/libbacktrace.a
+ LIBBACKTRACE_LIB=../libbacktrace/libbacktrace.la
AC_DEFINE(HAVE_LIBBACKTRACE, 1, [Define if libbacktrace is being used.])
else
LIBBACKTRACE_INC=
@@ -2151,15 +2155,10 @@ AC_ARG_WITH(xxhash,
[], [with_xxhash=auto])
GCC_ENABLE([libctf], [yes], [], [Handle .ctf type-info sections])
-if test x${enable_static} = xno; then
- LIBCTF="-Wl,--rpath,../libctf/.libs ../libctf/.libs/libctf.so"
- CTF_DEPS="../libctf/.libs/libctf.so"
-else
- LIBCTF="../libctf/.libs/libctf.a"
- CTF_DEPS="$LIBCTF"
-fi
if test "${enable_libctf}" = yes; then
AC_DEFINE(ENABLE_LIBCTF, 1, [Handle .ctf type-info sections])
+ LIBCTF="../libctf/libctf.la"
+ CTF_DEPS="../libctf/libctf.la"
else
LIBCTF=
CTF_DEPS=
@@ -154,7 +154,7 @@ global GDB_DATA_DIRECTORY
global inferior_spawn_id
if [info exists TOOL_EXECUTABLE] {
- set GDB $TOOL_EXECUTABLE
+ set GDB "libtool --mode=execute $TOOL_EXECUTABLE"
}
if ![info exists GDB] {
if ![is_remote host] {