diff options
author | Jose E. Marchesi <jose.marchesi@oracle.com> | 2022-11-05 11:52:09 +0100 |
---|---|---|
committer | Jose E. Marchesi <jose.marchesi@oracle.com> | 2022-11-06 14:01:49 +0100 |
commit | 39dea6107993b46e96d6ec85e61589a3b14f26cd (patch) | |
tree | e40068a50a25084ae66214a81fac30c22288537b /opcodes/mep-asm.c | |
parent | cb9bdc02fdf1650341276861f6ca7e7a215a1ce6 (diff) | |
download | gdb-users/jemarch/gdb-libtool.zip gdb-users/jemarch/gdb-libtool.tar.gz gdb-users/jemarch/gdb-libtool.tar.bz2 |
gdb: link executables with libtoolusers/jemarch/gdb-libtool
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,
BFD now refers to ../libbfd/libbfd.la
OPCODES now refers to ../opcodes/libopcodes.la
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.
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.
NOTE4: Now the installed shared object libbfd.so is used by gdb
if binutils is installed with --enable-shared.
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.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29372
Diffstat (limited to 'opcodes/mep-asm.c')
0 files changed, 0 insertions, 0 deletions