aboutsummaryrefslogtreecommitdiff
path: root/opcodes/mep-asm.c
diff options
context:
space:
mode:
authorJose E. Marchesi <jose.marchesi@oracle.com>2022-11-05 11:52:09 +0100
committerJose E. Marchesi <jose.marchesi@oracle.com>2022-11-06 14:01:49 +0100
commit39dea6107993b46e96d6ec85e61589a3b14f26cd (patch)
treee40068a50a25084ae66214a81fac30c22288537b /opcodes/mep-asm.c
parentcb9bdc02fdf1650341276861f6ca7e7a215a1ce6 (diff)
downloadgdb-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