aboutsummaryrefslogtreecommitdiff
path: root/gdb/configure
AgeCommit message (Collapse)AuthorFilesLines
40 hoursgcore: add -v or --version option to show version numberAndrew Burgess1-3/+2
Based on the work in this commit: commit fb2ded33c1e519659743047ed7817166545b6d91 Date: Fri Dec 20 12:46:11 2024 -0800 Add gstack script This commit adds a '-v' or '--version' option to the existing gcore script. This new option causes the script to print its version number, and then exit. I needed to adjust the getopts handling a little in order to support the long form '--version' argument, but as this makes gcore more consistent with gstack, then this seems like a good thing. The usage message is now getting a little long. Don't worry, I plan to clean that up in the next commit. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32325 Approved-By: Tom Tromey <tom@tromey.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2025-02-05gdb: restrict configure error with all targets and 64 bit bfd to mipsGuinevere Larsen1-3/+10
The recent commit b601c58034ed755fb765fc13782b6876bffd25d4 causes the gdb configure to fail if --enable-targets=all was requested, but 64 bit bfd was not enabled. This was due to a build failure first reported against mips, and that I also encountered building on a 32 bit mips system, but that looked like a general failure. Further examination showed that this is, in fact, mips-specific (or at least, not completely generic) as other targets like debian-i386 and 32-bit arm could build all targets just fine. This commit restricts the new error to only trigger in mips hosts. Approved-By: Andrew Burgess <aburgess@redhat.com>
2025-01-28gdb/configure: fail configure if all targets requested with 32bit bfdGuinevere Larsen1-1/+3
As PR sim/28684 explains, it isn't possible to compile GDB with all targets enabled and not enabling 64 bit bfd. In 64 bit hosts, 64 bit bfd is forced, so the build works, but in 32 bit hosts, that has to be explicitly enabled. I ran into this when I tried compiling GDB on a mips64 machine running a 32 bit OS. Along with the errors in the PR, several other architectures are also required, notably aarch64 and other explicitly 64bit targets. Additionally, some 32 bit files required for the gdb mips target aren't added to the makefile. Considering the last comment in the bug says this isn't going to be fixed on the binutils side, I didn't think it was worth trying to fix the GDB side. Instead, this commit causes the configure script to fail if all targets were requested and 64 bit bfd isn't enabled. If that is ever fixed, we can revert this commit. I considered adding this to the top level configure script, but couldn't figure out how to detect the situation in there, so this was my next best idea. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28684 Approved-by: Kevin Buettner <kevinb@redhat.com>
2024-12-20Add gstack scriptKeith Seitz1-2/+12
This commit adds support for a `gstack' command which Fedora has been carrying for many years. gstack is a natural counterpart to the gcore command. Whereas gcore dumps a core file, gstack prints stack traces of a running process. There are many improvements over Fedora's version of this script. The dependency on procfs is gone; gstack will run anywhere gdb runs. The only runtime dependencies are bash and awk. The script includes suggestions from gdb/32325 to include versioning and help. [If this approach to gdb/32325 is acceptable, I could propagate the solution to gcore/gdb-add-index.] I've rewritten the documentation, integrating it into the User Manual. The manpage is now output using this one source. Example run (on x86_64 Fedora 40) $ gstack --help Usage: gstack [-h|--help] [-v|--version] PID Print a stack trace of a running program -h, --help Print this message then exit. -v, --version Print version information then exit. $ gstack -v GNU gstack (GDB) 16.0.50.20241119-git $ gstack 12345678 Process 12345678 not found. $ gstack $(pidof emacs) Thread 6 (Thread 0x7fd5ec1c06c0 (LWP 2491423) "pool-spawner"): #0 0x00007fd6015ca3dd in syscall () at /lib64/libc.so.6 #1 0x00007fd60b31eccd in g_cond_wait () at /lib64/libglib-2.0.so.0 #2 0x00007fd60b28a61b in g_async_queue_pop_intern_unlocked () at /lib64/libglib-2.0.so.0 #3 0x00007fd60b2f1a03 in g_thread_pool_spawn_thread () at /lib64/libglib-2.0.so.0 #4 0x00007fd60b2f0813 in g_thread_proxy () at /lib64/libglib-2.0.so.0 #5 0x00007fd6015486d7 in start_thread () at /lib64/libc.so.6 #6 0x00007fd6015cc60c in clone3 () at /lib64/libc.so.6 #7 0x0000000000000000 in ??? () Thread 5 (Thread 0x7fd5eb9bf6c0 (LWP 2491424) "gmain"): #0 0x00007fd6015be87d in poll () at /lib64/libc.so.6 #1 0x0000000000000001 in ??? () #2 0xffffffff00000001 in ??? () #3 0x0000000000000001 in ??? () #4 0x000000002104cfd0 in ??? () #5 0x00007fd5eb9be320 in ??? () #6 0x00007fd60b321c34 in g_main_context_iterate_unlocked.isra () at /lib64/libglib-2.0.so.0 Thread 4 (Thread 0x7fd5eb1be6c0 (LWP 2491425) "gdbus"): #0 0x00007fd6015be87d in poll () at /lib64/libc.so.6 #1 0x0000000020f9b558 in ??? () #2 0xffffffff00000003 in ??? () #3 0x0000000000000003 in ??? () #4 0x00007fd5d8000b90 in ??? () #5 0x00007fd5eb1bd320 in ??? () #6 0x00007fd60b321c34 in g_main_context_iterate_unlocked.isra () at /lib64/libglib-2.0.so.0 Thread 3 (Thread 0x7fd5ea9bd6c0 (LWP 2491426) "emacs"): #0 0x00007fd6015ca3dd in syscall () at /lib64/libc.so.6 #1 0x00007fd60b31eccd in g_cond_wait () at /lib64/libglib-2.0.so.0 #2 0x00007fd60b28a61b in g_async_queue_pop_intern_unlocked () at /lib64/libglib-2.0.so.0 #3 0x00007fd60b28a67c in g_async_queue_pop () at /lib64/libglib-2.0.so.0 #4 0x00007fd603f4d0d9 in fc_thread_func () at /lib64/libpangoft2-1.0.so.0 #5 0x00007fd60b2f0813 in g_thread_proxy () at /lib64/libglib-2.0.so.0 #6 0x00007fd6015486d7 in start_thread () at /lib64/libc.so.6 #7 0x00007fd6015cc60c in clone3 () at /lib64/libc.so.6 #8 0x0000000000000000 in ??? () Thread 2 (Thread 0x7fd5e9e6d6c0 (LWP 2491427) "dconf worker"): #0 0x00007fd6015be87d in poll () at /lib64/libc.so.6 #1 0x0000000000000001 in ??? () #2 0xffffffff00000001 in ??? () #3 0x0000000000000001 in ??? () #4 0x00007fd5cc000b90 in ??? () #5 0x00007fd5e9e6c320 in ??? () #6 0x00007fd60b321c34 in g_main_context_iterate_unlocked.isra () at /lib64/libglib-2.0.so.0 Thread 1 (Thread 0x7fd5fcc45280 (LWP 2491417) "emacs"): #0 0x00007fd6015c9197 in pselect () at /lib64/libc.so.6 #1 0x0000000000000000 in ??? () Since this is essentially a complete rewrite of the original script and documentation, I've chosen to only keep a 2024 copyright date. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
2024-12-04[gdb/build] Fix build breaker on mingw-w64Simon Marchi1-1/+0
The mingw-w64 build breaks currently: ... In file included from gdb/cli/cli-cmds.c:58: gdbsupport/eintr.h: In function ‘pid_t gdb::waitpid(pid_t, int*, int)’: gdbsupport/eintr.h:77:35: error: ‘::waitpid’ has not been declared; \ did you mean ‘gdb::waitpid’? 77 | return gdb::handle_eintr (-1, ::waitpid, pid, wstatus, options); | ^~~~~~~ | gdb::waitpid gdbsupport/eintr.h:75:1: note: ‘gdb::waitpid’ declared here 75 | waitpid (pid_t pid, int *wstatus, int options) | ^~~~~~~ ... This is a regression since commit 658a03e9e85 ("[gdbsupport] Add gdb::{waitpid,read,write,close}"), which moved the use of ::waitpid from run_under_shell, where it was used conditionally: ... #if defined(CANT_FORK) || \ (!defined(HAVE_WORKING_VFORK) && !defined(HAVE_WORKING_FORK)) ... #else ... int ret = gdb::handle_eintr (-1, ::waitpid, pid, &status, 0); ... to gdb::waitpid, where it's used unconditionally: ... inline pid_t waitpid (pid_t pid, int *wstatus, int options) { return gdb::handle_eintr (-1, ::waitpid, pid, wstatus, options); } ... Likewise for ::wait. Guard these uses with HAVE_WAITPID and HAVE_WAIT. Reproduced and tested by doing a mingw-w64 cross-build on x86_64-linux. Reported-By: Simon Marchi <simark@simark.ca> Co-Authored-By: Tom de Vries <tdevries@suse.de>
2024-12-02gdb/configure.ac: remove elf_hp.h checkSimon Marchi1-2/+0
The comment says this is for HP/UX, which is no longer supported. There should be no functional changes with this, since nothing checks HAVE_ELF_HP_H. Change-Id: Ie897fc64638c9fea28463e1bf69e450c3673fd84
2024-12-02gdb, gdbserver, gdbsupport: flatten and sort some list in configure filesSimon Marchi1-18/+88
This makes the lists easier sort read and modify. There are no changes in the generated config.h files, so I'm confident this brings no functional changes. Change-Id: Ib6b7fc532bcd662af7dbb230070fb1f4fc75f86b
2024-11-23[gdb/contrib] Add two rules in common-misspellings.txtTom de Vries1-1/+1
Eli mentioned [1] that given that we use US English spelling in our documentation, we should use "behavior" instead of "behaviour". In wikipedia-common-misspellings.txt there's a rule: ... behavour->behavior, behaviour ... which leaves this as a choice. Add an overriding rule to hardcode the choice to common-misspellings.txt: ... behavour->behavior ... and add a rule to rewrite behaviour into behavior: ... behaviour->behavior ... and re-run spellcheck.sh on gdb*. Tested on x86_64-linux. [1] https://sourceware.org/pipermail/gdb-patches/2024-November/213371.html
2024-10-08gdb: include --enable-targets in 'show configuration' outputAndrew Burgess1-1/+9
Include the value of configuration flag --enable-targets in the output of GDB command 'show configuration' and also in the output printed for 'gdb --configuration'. This will make it easier to see how GDB was built. No tests added or updated as we can't really check for a specific flag appearing or not appearing on the configuration output. But we do print the configuration within lib/gdb.exp to check which features are built into GDB, so if this change broke configuration printing then plenty of tests should stop working (they don't). Approved-By: Tom Tromey <tom@tromey.com>
2024-08-14btrace, python: Enable ptwrite filter registration.Felix Willgerodt1-0/+11
By default GDB will be printing the hex payload of the ptwrite package as auxiliary information. To customize this, the user can register a ptwrite filter function in python, that takes the payload and the PC as arguments and returns a string which will be printed instead. Registering the filter function is done using a factory pattern to make per-thread filtering easier. Approved-By: Markus Metzger <markus.t.metzger@intel.com>
2024-08-12gdb/amd-dbgapi-target: adjust to amd-dbgapi 0.75.0Simon Marchi1-10/+10
amd-dbgapi 0.75 (from ROCm release 6.2.0) brings a few backwards incompatible changes. Adjust the amd-dbgapi target code accordingly. Given that the AMD GPU port in upstream GDB today is of limited use (it's still missing important pieces), we don't really care about supporting amd-dbgapi versions other than the latest stable one, so no effort is made to keep compatibility with versions 6.1.2 and older. The changes are: - AMD_DBGAPI_EXCEPTION_WAVE_APERTURE_VIOLATION was renamed to AMD_DBGAPI_EXCEPTION_WAVE_ADDRESS_ERROR (the old name still exists but is deprecated), use the latter. - In the callbacks structure, the get_os_pid callback was replaced with client_process_get_info, which is more general and extensible. Convert our get_os_pid to a new, equivalent, client_process_get_info callback. Handle the new AMD_DBGAPI_CLIENT_PROCESS_INFO_CORE_STATE query, but just return "not available". - The xfer_global_memory callback was added to the callbacks structure, add that new callback. - Update configure.ac to check for amd-dbgapi >= 0.75.0. Change-Id: If012398cf55ebf6146b007f6b4e8395dd48ef981 Approved-By: Lancelot Six <lancelot.six@amd.com> Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
2024-08-02gdb, gdbserver, gdbsupport: remove -Wno-vla-cxx-extensionSimon Marchi1-1/+1
Now that all known uses of VLAs within GDB are removed, remove the `-Wno-vla-cxx-extension` (which was used to silence clang warnings) and add `-Wvla`, such that any use of a VLA will trigger a warning. Change-Id: I69a8d7f93f973743165b0ba46f9c2ea8adb89025 Reviewed-By: Keith Seitz <keiths@redhat.com>
2024-06-20Revert "Remove LIBINTL_DEP"Alan Modra1-2/+4
This reverts commit e874cbd3879843a83e4bcc4b54cd7107387b1df6. The patch was wrong. LIBINTL_DEP is needed with an in-tree gettext.
2024-06-20Remove LIBINTL_DEPAlan Modra1-4/+2
The intl directory in the source no longer exists. LIBINTL_DEP is thus always empty. Remove references to it. config/ * gettext-sister.m4: Don't AC_SUBST LIBINTL_DEP. bfd/ * Makefile.in: Regenerate. * configure: Regenerate. binutils/ * Makefile.am (*_DEPENDENCIES): Remove LIBINTL_DEP. * Makefile.in: Regenerate. * configure: Regenerate. gas/ * Makefile.am (as_new_DEPENDENCIES): Remove LIBINTL_DEP. * Makefile.in: Regenerate. * configure: Regenerate. gdb/ * Makefile.in (INTL_DEPS): Don't set or reference. * configure: Regenerate. gdbserver/ * Makefile.in (INTL_DEPS): Don't set or reference. gdbsupport/ * Makefile.in: Regenerate. * configure: Regenerate. gold/ * Makefile.am (deps_var): Remove LIBINTL_DEP. (incremental_dump_DEPENDENCIES, dwp_DEPENDENCIES): Likewise. * Makefile.in: Regenerate. * configure: Regenerate. * testsuite/Makefile.am (DEPENDENCIES): Remove LIBINTL_DEP. * testsuite/Makefile.in: Regenerate. gprof/ * Makefile.am (gprof_DEPENDENCIES): Remove LIBINTL_DEP. * Makefile.in: Regenerate. * configure: Regenerate. ld/ * Makefile.am (ld_new_DEPENDENCIES): Remove LIBINTL_DEP. * Makefile.in: Regenerate. * configure: Regenerate. libctf/ * Makefile.in: Regenerate. * configure: Regenerate. opcodes/ * configure.ac (BUILD_LIBS): Remove LIBINTL. (BUILD_LIB_DEPS): Remove LIBINTL_DEP. * Makefile.in: Regenerate. * configure: Regenerate.
2024-06-08Fix typo in warning in gdb/configureTom Tromey1-2/+2
Eli pointed out that "babeltrace" is misspelled in a warning in gdb/configure. This patch fixes the typo.
2024-05-16Stop 'configure --enable-threading' if std::thread doesn't workPedro Alves1-3/+11
Currently, if you configure gdb with explicit --enable-threading, but then configure detects std::thread does not work, configure silently disables threading support and continues configuring. This patch makes that scenario cause a configuration error, like so: $ /home/pedro/gdb/src/configure --enable-threading && make ... configure: error: std::thread does not work; disable threading make[1]: *** [Makefile:11225: configure-gdbsupport] Error 1 make[1]: Leaving directory '/home/pedro/gdb/build-windows-threads' make: *** [Makefile:1041: all] Error 2 $ Additionally, if you don't explicitly pass --enable-threading, and std::thread does not work, we will now get a warning (and the build continues): $ /home/pedro/gdb/src/configure && make ... configure: WARNING: std::thread does not work; disabling threading ... This is similar to how we handle --enable-tui and missing curses. The code and error/warning messages were borrowed from there. Change-Id: I73a8b580d1e2a796b23136920c0e181408ae1b22 Approved-By: Tom Tromey <tom@tromey.com>
2024-05-06Fix build issues with mingw toolchainBernd Edlinger1-0/+1
With a x86_64-pc-mingw32 toolchain there is a build issue whether or not the --disable-threading option is used. The problem happens because _WIN32_WINNT is defined to 0x501 before #include <mutex> which makes the compilation abort due to missing support for __gthread_cond_t in std_mutex.h, which is conditional on _WIN32_WINNT >= 0x600. Fix the case when --disable-threading is used, by only including <mutex> in gdb/complaints.c when STD_CXX_THREAD is defined. Additionally make the configure script try to #include <mutex> to automatically select --disable-threading when the header file is not able to compile. Approved-By: Tom Tromey <tom@tromey.com>
2024-04-17gdbsupport, gdbserver, gdb: use -Wno-vla-cxx-extensionSimon Marchi1-0/+1
When building with clang 18, I see: CXX aarch64-linux-tdep.o /home/smarchi/src/binutils-gdb/gdb/aarch64-linux-tdep.c:1299:26: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension] 1299 | gdb_byte za_zeroed[za_bytes]; | ^~~~~~~~ /home/smarchi/src/binutils-gdb/gdb/aarch64-linux-tdep.c:1299:26: note: read of non-const variable 'za_bytes' is not allowed in a constant expression /home/smarchi/src/binutils-gdb/gdb/aarch64-linux-tdep.c:1282:10: note: declared here 1282 | size_t za_bytes = std::pow (sve_vl_from_vg (svg), 2); | ^ Since we are using VLAs right now, that warning doesn't make sense for us. add `-Wno-vla-cxx-extension` to the list of warning flags we try to enable. If we ever choose to disallow VLAs, we can remove that flag. Change-Id: Ie41feafc50c343f6e75333d4f836ce32fbeb6d8c
2024-04-08gdb/configure: realign the AC_ARG_ENABLE(sim, ....) blockAndrew Burgess1-6/+6
Following the suggestion in this review comment: https://inbox.sourceware.org/gdb-patches/9420bbb0-2614-4847-9157-8562f8a62d03@simark.ca this commit realigns the AC_ARG_ENABLE(sim, ....) block. I've added additional [...] quoting in a couple of places, which is inline with how other AC_ARG_ENABLE blocks are formatted within GDB's configure.ac file. There should be no change in how GDB configures or builds after this commit.
2024-04-08gdb/configure: use AC_MSG_NOTICE not a direct echo callAndrew Burgess1-2/+4
After the recent commits, I noticed that GDB's configure script would still emit two lines even when run in silent mode. If you touch gdb/Makefile.in and then run 'make all' in the gdb/ build directory you'll see this: GEN config.status enable_sim = no enableval = no Obviously the 'no' might be 'yes' depending on how you actually configured GDB. This is caused by two direct invocations of 'echo' in GDB's configure.ac script. In this commit I replace these calls with use of AC_MSG_NOTICE instead. Now when configure is run with the --silent command line option these lines will not be printed. There should be no changes in the built GDB after this commit. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-01-10gdbsupport: tighten up libiberty code a bit with dnlMike Frysinger1-3/+1
No functional change here, just touch up generated output slightly. Approved-By: Tom Tromey <tom@tromey.com>
2024-01-10gdb: libiberty: switch to AC_CHECK_DECLS_ONCEMike Frysinger1-58/+69
Only check these decls once in case other m4 macros also look for them. Approved-By: Tom Tromey <tom@tromey.com>
2023-11-30[gdb/build] Fix adding -DNDEBUG to python flags of release buildTom de Vries1-3562/+3563
In gdb/configure the line: ... $development || tentative_python_cflags="$tentative_python_cflags -DNDEBUG" ... intends to ensure that -DNDEBUG is added to the python flags of a release build. However, when building gdb-14-branch we have: ... configure:22024: checking compiler flags for python code ... configure:22047: result: -fno-strict-aliasing -fwrapv ... This is a regression since commit db6878ac553 ("Move sourcing of development.sh to GDB_AC_COMMON"), which introduced a reference before assignment: ... $development || tentative_python_cflags="$tentative_python_cflags -DNDEBUG" ... . $srcdir/../bfd/development.sh ... and consequently -DNDEBUG is never added. [ This was not obvious to me, but apparently evaluating an empty or undefined variable in this context is similar to using ':' or 'true', so the line is evaluated as: ... true || tentative_python_cflags="$tentative_python_cflags -DNDEBUG" ... ] Fix this by moving GDB_AC_COMMON up in gdb/configure.ac, similar to how that was done for gdbserver/configure.ac in commit db6878ac553. [ Unfortunately, the move might introduce issues similar to the one we're fixing, and I'm not sure how to check for this. Shellcheck doesn't detect this type of problem. FWIW, I did run shellcheck (using arguments -xa, in the src/gdb directory to make sure ../bfd/development.sh is taken into account) before and after and observed that the number of lines/words/chars in the shellcheck output is identical. ] Build & tested on top of trunk. Also build on top of gdb-14-branch, and observed this in gdb/config.log: ... configure:25214: checking compiler flags for python code ... configure:25237: result: -fno-strict-aliasing -fwrapv -DNDEBUG ... Approved-By: Tom Tromey <tom@tromey.com> PR build/31099 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31099
2023-11-29Switch to -Wimplicit-fallthrough=5Tom Tromey1-1/+1
This changes the various gdb-related directories to use -Wimplicit-fallthrough=5, meaning that only the fallthrough attribute can be used in switches -- special 'fallthrough' comments will no longer be usable. Approved-By: Pedro Alves <pedro@palves.net>
2023-11-15Finalized intl-update patchesArsen Arsenovi?1-752/+2404
* intl: Remove directory. Replaced with out-of-tree GNU gettext. * .gitignore: Add '/gettext*'. * configure.ac (host_libs): Replace intl with gettext. (hbaseargs, bbaseargs, baseargs): Split baseargs into {h,b}baseargs. (skip_barg): New flag. Skips appending current flag to bbaseargs. <library exemptions>: Exempt --with-libintl-{type,prefix} from target and build machine argument passing. * configure: Regenerate. * Makefile.def (host_modules): Replace intl module with gettext module. (configure-ld): Depend on configure-gettext. * Makefile.in: Regenerate. * src-release.sh: Remove references to the intl/ directory.
2023-10-28gdb/gdbsupport/gdbserver: Require c++17Lancelot Six1-25/+1519
This patch proposes to require a C++17 compiler to build gdb / gdbsupport / gdbserver. Before this patch, GDB required a C++11 compiler. The general policy regarding bumping C++ language requirement in GDB (as stated in [1]) is: Our general policy is to wait until the oldest compiler that supports C++NN is at least 3 years old. Rationale: We want to ensure reasonably widespread compiler availability, to lower barrier of entry to GDB contributions, and to make it easy for users to easily build new GDB on currently supported stable distributions themselves. 3 years should be sufficient for latest stable releases of distributions to include a compiler for the standard, and/or for new compilers to appear as easily installable optional packages. Requiring everyone to build a compiler first before building GDB, which would happen if we required a too-new compiler, would cause too much inconvenience. See the policy proposal and discussion [here](https://sourceware.org/ml/gdb-patches/2016-10/msg00616.html). The first GCC release which with full C++17 support is GCC-9[2], released in 2019[3], which is over 4 years ago. Clang has had C++17 support since Clang-5[4] released in 2018[5]. A discussions with many distros showed that a C++17-able compiler is always available, meaning that this no hard requirement preventing us to require it going forward. [1] https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#When_is_GDB_going_to_start_requiring_C.2B-.2B-NN_.3F [2] https://gcc.gnu.org/projects/cxx-status.html#cxx17 [3] https://gcc.gnu.org/gcc-9/ [4] https://clang.llvm.org/cxx_status.html [5] https://releases.llvm.org/ Change-Id: Id596f5db17ea346e8a978668825787b3a9a443fd Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>
2023-10-28gdb/ax_cxx_compile_stdcxx.m4: upgradeLancelot Six1-10/+34
This patch upgrades gdb/ax_cxx_compile_stdcxx.m4 to follow changes available in [1] and regenerates the configure script. [1] https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx.html Change-Id: I5b16adc65c9e48a13ad65202d58ab7a9d487214e Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>
2023-10-12Move -lsocket check to common.m4Tom Tromey1-60/+59
A user pointed out that the -lsocket check in gdb should also apply to gdbserver -- otherwise it can't find the Solaris socketpair. This patch makes the change. It also removes a couple of redundant function checks from gdb's configure.ac. This was tested by the person who reported the bug. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30927 Approved-By: Pedro Alves <pedro@palves.net>
2023-10-05gdb/configure.ac: Add option --with-additional-debug-dirsThiago Jung Bauermann1-2/+17
If you want to install GDB in a custom prefix, have it look for debug info in that prefix but also in the distro's default location (typically, /usr/lib/debug) and run the GDB testsuite before doing "make install", you have a bit of a problem: Configuring GDB with '--prefix=$PREFIX' sets the GDB 'debug-file-directory' parameter to $PREFIX/lib/debug. Unfortunately this precludes GDB from looking for distro-installed debug info in /usr/lib/debug. For regular GDB use you could set debug-file-directory to $PREFIX:/usr/lib/debug in $PREFIX/etc/gdbinit so that GDB will look in both places, but if you want to run the testsuite then that doesn't help because in that case GDB runs with the '-nx' option. There's the configure option '--with-separate-debug-dir' to set the default value for 'debug-file-directory', but it accepts only one directory and not a list. I considered modifying it to accept a list, but it's not obvious how to do that because its value is also used by BFD, as well as processed for "relocatability". I thought it was simpler to add a new option to specify a list of additional directories that will be appended to the debug-file-directory setting. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
2023-09-27config/debuginfod.m4: Add check for libdebuginfod 0.188Aaron Merey1-1/+107
Add check for libdebuginfod 0.188 in AC_DEBUGINFOD and if found define macro HAVE_LIBDEBUGINFOD_FIND_SECTION. This macro indicates support for downloading ELF sections from debuginfod servers.
2023-08-12regen configAlan Modra1-30/+86
This regenerates config files changed by the previous 44 commits. Note that subject lines in these commits mostly match the gcc git originating commit.
2023-07-12[gdb/tui] Assume HAVE_WBORDERTom de Vries1-1/+1
The tui border-kind setting allows values acs, ascii and space. The values ascii and space however don't work well with !HAVE_WBORDER. Fix this by removing the !HAVE_WBORDER case, which was introduced for Ultrix support, which is now obsolete. Tested on x86_64-linux. PR tui/30580 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30580 Approved-By: Tom Tromey <tom@tromey.com>
2023-03-07gdb: Fix GDB_AC_CHECK_BFD macro regressionRichard Purdie1-2/+2
Commit 5218fa9e8937b007d554f1e01c2e4ecdb9b7e271, "gdb: use libtool in GDB_AC_CHECK_BFD" dropped passing in existing LDFLAGS. In our environment, this caused the configure check "checking for ELF support in BFD" to stop working causing build failures as we need our LDFLAGS to be used for correct linking. That change also meant the code failed to match the comments. Add back the missing LDFLAGS preservation, fix our builds and match the comment. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Change-Id: Ie91509116fab29f95b9db1ff0b6ddc280d460112 Approved-By: Simon Marchi <simon.marchi@efficios.com> Reviewed-By: Jose E. Marchesi <jose.marchesi@oracle.com>
2023-02-23gdb: remove --disable-gdbmi configure optionSimon Marchi1-29/+2
I noticed that the --disable-gdbmi option was broken for almost a year (since 740b42ceb7c "gdb/python/mi: create MI commands using python"). The problem today is the python/py-cmd.c file. It is included in the build if Python support is enabled, and it calls into some MI functions (e.g. insert_mi_cmd_entry). If MI support is disabled, we get some undefined symbols like: mold: error: undefined symbol: insert_mi_cmd_entry(std::unique_ptr<mi_command, std::default_delete<mi_command> >) >>> referenced by py-micmd.c >>> python/py-micmd.o:(micmdpy_install_command(micmdpy_object*)) The python/py-cmd.c file should be included in the build if both Python and MI support are enabled. It is not a case we support today, but it could be done with a bit more configure code. However, I think we should just remove the --disable-gdbmi option, and just include MI support unconditionally. Tom Tromey proposed a while ago to remove this option, but it ended staying: https://inbox.sourceware.org/gdb-patches/20180628172132.28843-1-tom@tromey.com/ However, there was no strong opposition to remove it. The argument was just "bah, it doesn't hurt anybody". But given today's case, I would rather remove complexity rather than add some. I couldn't find anybody caring deeply for that option, and it's not like MI adds any external dependency. It's just a bit more code. Removing the option will not break anybody using --disable-gdbmi (it can be found in many build scripts [1]), since we don't flag invalid configure flags. So, remove the option from configure.ac, and adjust Makefile.in accordingly to always include the MI objects in the build. [1] https://github.com/search?q=%22--disable-gdbmi%22&type=code Change-Id: Ifcaa8c9fc4abc6fa686ed5fd984598644f745240 Approved-By: Tom Tromey <tom@tromey.com>
2023-02-21gdb: add --with-curses to --configuration outputPhilippe Blain1-4/+4
'gdb --configuration' does not mention if GDB was built with curses. Since b5075fb68d4 (Rename to allow_tui_tests, 2023-01-08) it does show --enable-tui (or --disable-tui), but one might want to know if GDB was built with curses independently of the availability of the TUI. Since configure.ac uses AC_SEARCH_LIBS to check for the curses library, we do not get an automatically defined HAVE_LIBCURSES symbol in config.in. We do have symbols defined by AC_CHECK_HEADERS (HAVE_CURSES_H, etc.) but it would be cumbersome to use those in print_gdb_configuration because we would have to check for all 6 symbols corresponding the 6 headers listed. This would also increase the maintenance burden if support for other variations of curses are added. Instead, define 'HAVE_LIBCURSES' ourselves by adding an 'action-if-found' argument to AC_SEARCH_LIBS, and use it in print_gdb_configuration. While at it, remove the condition on 'ac_cv_search_waddstr' and set 'curses_found' directly in 'action-if-found'. Change-Id: Id90e3d73990e169cee51bcc3e1d52072cfacd5b8 Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-14gdb: remove unnecessary tui directory check in configureSimon Marchi1-11/+9
I suppose this was possible in the CVS days for the tui directory to be missing, but it's not really possible nowaday. Well, a user could delete the directory from their source tree but... it doesn't make sense. Remove the check for that directory in configure. Change-Id: Iea1412f5e5482ed003015030132ec22150c7d0b3 Approved-By: Tom Tromey <tom@tromey.com>
2023-02-13Fix doc build dependencies for --with-system-readlineKeith Seitz1-2/+6
PR build/30108 concerns building gdb documentation with --with-sytem-readline. If the in-tree readline directory is missing, though, the docs will fail to build: make[4]: Entering directory '/home/keiths/work/readline-doc-issue/linux/gdb/doc' make[4]: *** No rule to make target '../../../src/gdb/doc/../../readline/readline/doc/rluser.texi', needed by 'gdb.info'. Stop. The listed file (and hsuser.texi) are conditionally included by gdb.texinfo. When system readline is used, gdb/configure.ac will leave READLINE_TEXI_INCFLAGS empty, causing doc/Makefile.in to output a line to $BUILD/doc/GDBvn.texi with "@set SYSTEM_READLINE". This surpresses the inclusion of the missing files. They are not needed or used in this scenario. However, GDB_DOC_SOURCE_INCLUDES always lists these two files as dependencies, thus provoking the build error whenever readline/ is missing. This patch fixes this by creating (essentially) a conditional setting of the dependencies to be included from readline.
2023-02-13gdb: 'show config' shows --with[out]-amd-dbgapiLancelot SIX1-0/+3
Ensure that the "show configuration" command and the "--configuration" command line switch shows if GDB was built with the AMDGPU support or not. This will be used in a later patch in this series. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-02gdb: initial support for ROCm platform (AMDGPU) debuggingSimon Marchi1-130/+295
This patch adds the foundation for GDB to be able to debug programs offloaded to AMD GPUs using the AMD ROCm platform [1]. The latest public release of the ROCm release at the time of writing is 5.4, so this is what this patch targets. The ROCm platform allows host programs to schedule bits of code for execution on GPUs or similar accelerators. The programs running on GPUs are typically referred to as `kernels` (not related to operating system kernels). Programs offloaded with the AMD ROCm platform can be written in the HIP language [2], OpenCL and OpenMP, but we're going to focus on HIP here. The HIP language consists of a C++ Runtime API and kernel language. Here's an example of a very simple HIP program: #include "hip/hip_runtime.h" #include <cassert> __global__ void do_an_addition (int a, int b, int *out) { *out = a + b; } int main () { int *result_ptr, result; /* Allocate memory for the device to write the result to. */ hipError_t error = hipMalloc (&result_ptr, sizeof (int)); assert (error == hipSuccess); /* Run `do_an_addition` on one workgroup containing one work item. */ do_an_addition<<<dim3(1), dim3(1), 0, 0>>> (1, 2, result_ptr); /* Copy result from device to host. Note that this acts as a synchronization point, waiting for the kernel dispatch to complete. */ error = hipMemcpyDtoH (&result, result_ptr, sizeof (int)); assert (error == hipSuccess); printf ("result is %d\n", result); assert (result == 3); return 0; } This program can be compiled with: $ hipcc simple.cpp -g -O0 -o simple ... where `hipcc` is the HIP compiler, shipped with ROCm releases. This generates an ELF binary for the host architecture, containing another ELF binary with the device code. The ELF for the device can be inspected with: $ roc-obj-ls simple 1 host-x86_64-unknown-linux file://simple#offset=8192&size=0 1 hipv4-amdgcn-amd-amdhsa--gfx906 file://simple#offset=8192&size=34216 $ roc-obj-extract 'file://simple#offset=8192&size=34216' $ file simple-offset8192-size34216.co simple-offset8192-size34216.co: ELF 64-bit LSB shared object, *unknown arch 0xe0* version 1, dynamically linked, with debug_info, not stripped ^ amcgcn architecture that my `file` doesn't know about ----´ Running the program gives the very unimpressive result: $ ./simple result is 3 While running, this host program has copied the device program into the GPU's memory and spawned an execution thread on it. The goal of this GDB port is to let the user debug host threads and these GPU threads simultaneously. Here's a sample session using a GDB with this patch applied: $ ./gdb -q -nx --data-directory=data-directory ./simple Reading symbols from ./simple... (gdb) break do_an_addition Function "do_an_addition" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (do_an_addition) pending. (gdb) r Starting program: /home/smarchi/build/binutils-gdb-amdgpu/gdb/simple [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7ffff5db7640 (LWP 1082911)] [New Thread 0x7ffef53ff640 (LWP 1082913)] [Thread 0x7ffef53ff640 (LWP 1082913) exited] [New Thread 0x7ffdecb53640 (LWP 1083185)] [New Thread 0x7ffff54bf640 (LWP 1083186)] [Thread 0x7ffdecb53640 (LWP 1083185) exited] [Switching to AMDGPU Wave 2:2:1:1 (0,0,0)/0] Thread 6 hit Breakpoint 1, do_an_addition (a=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>, b=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>, out=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>) at simple.cpp:24 24 *out = a + b; (gdb) info inferiors Num Description Connection Executable * 1 process 1082907 1 (native) /home/smarchi/build/binutils-gdb-amdgpu/gdb/simple (gdb) info threads Id Target Id Frame 1 Thread 0x7ffff5dc9240 (LWP 1082907) "simple" 0x00007ffff5e9410b in ?? () from /opt/rocm-5.4.0/lib/libhsa-runtime64.so.1 2 Thread 0x7ffff5db7640 (LWP 1082911) "simple" __GI___ioctl (fd=3, request=3222817548) at ../sysdeps/unix/sysv/linux/ioctl.c:36 5 Thread 0x7ffff54bf640 (LWP 1083186) "simple" __GI___ioctl (fd=3, request=3222817548) at ../sysdeps/unix/sysv/linux/ioctl.c:36 * 6 AMDGPU Wave 2:2:1:1 (0,0,0)/0 do_an_addition ( a=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>, b=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>, out=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>) at simple.cpp:24 (gdb) bt Python Exception <class 'gdb.error'>: Unhandled dwarf expression opcode 0xe1 #0 do_an_addition (a=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>, b=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>, out=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>) at simple.cpp:24 (gdb) continue Continuing. result is 3 warning: Temporarily disabling breakpoints for unloaded shared library "file:///home/smarchi/build/binutils-gdb-amdgpu/gdb/simple#offset=8192&size=67208" [Thread 0x7ffff54bf640 (LWP 1083186) exited] [Thread 0x7ffff5db7640 (LWP 1082911) exited] [Inferior 1 (process 1082907) exited normally] One thing to notice is the host and GPU threads appearing under the same inferior. This is a design goal for us, as programmers tend to think of the threads running on the GPU as part of the same program as the host threads, so showing them in the same inferior in GDB seems natural. Also, the host and GPU threads share a global memory space, which fits the inferior model. Another thing to notice is the error messages when trying to read variables or printing a backtrace. This is expected for the moment, since the AMD GPU compiler produces some DWARF that uses some non-standard extensions: https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html There were already some patches posted by Zoran Zaric earlier to make GDB support these extensions: https://inbox.sourceware.org/gdb-patches/20211105113849.118800-1-zoran.zaric@amd.com/ We think it's better to get the basic support for AMD GPU in first, which will then give a better justification for GDB to support these extensions. GPU threads are named `AMDGPU Wave`: a wave is essentially a hardware thread using the SIMT (single-instruction, multiple-threads) [3] execution model. GDB uses the amd-dbgapi library [4], included in the ROCm platform, for a few things related to AMD GPU threads debugging. Different components talk to the library, as show on the following diagram: +---------------------------+ +-------------+ +------------------+ | GDB | amd-dbgapi target | <-> | AMD | | Linux kernel | | +-------------------+ | Debugger | +--------+ | | | amdgcn gdbarch | <-> | API | <=> | AMDGPU | | | +-------------------+ | | | driver | | | | solib-rocm | <-> | (dbgapi.so) | +--------+---------+ +---------------------------+ +-------------+ - The amd-dbgapi target is a target_ops implementation used to control execution of GPU threads. While the debugging of host threads works by using the ptrace / wait Linux kernel interface (as usual), control of GPU threads is done through a special interface (dubbed `kfd`) exposed by the `amdgpu` Linux kernel module. GDB doesn't interact directly with `kfd`, but instead goes through the amd-dbgapi library (AMD Debugger API on the diagram). Since it provides execution control, the amd-dbgapi target should normally be a process_stratum_target, not just a target_ops. More on that later. - The amdgcn gdbarch (describing the hardware architecture of the GPU execution units) offloads some requests to the amd-dbgapi library, so that knowledge about the various architectures doesn't need to be duplicated and baked in GDB. This is for example for things like the list of registers. - The solib-rocm component is an solib provider that fetches the list of code objects loaded on the device from the amd-dbgapi library, and makes GDB read their symbols. This is very similar to other solib providers that handle shared libraries, except that here the shared libraries are the pieces of code loaded on the device. Given that Linux host threads are managed by the linux-nat target, and the GPU threads are managed by the amd-dbgapi target, having all threads appear in the same inferior requires the two targets to be in that inferior's target stack. However, there can only be one process_stratum_target in a given target stack, since there can be only one target per slot. To achieve it, we therefore resort the hack^W solution of placing the amd-dbgapi target in the arch_stratum slot of the target stack, on top of the linux-nat target. Doing so allows the amd-dbgapi target to intercept target calls and handle them if they concern GPU threads, and offload to beneath otherwise. See amd_dbgapi_target::fetch_registers for a simple example: void amd_dbgapi_target::fetch_registers (struct regcache *regcache, int regno) { if (!ptid_is_gpu (regcache->ptid ())) { beneath ()->fetch_registers (regcache, regno); return; } // handle it } ptids of GPU threads are crafted with the following pattern: (pid, 1, wave id) Where pid is the inferior's pid and "wave id" is the wave handle handed to us by the amd-dbgapi library (in practice, a monotonically incrementing integer). The idea is that on Linux systems, the combination (pid != 1, lwp == 1) is not possible. lwp == 1 would always belong to the init process, which would also have pid == 1 (and it's improbable for the init process to offload work to the GPU and much less for the user to debug it). We can therefore differentiate GPU and non-GPU ptids this way. See ptid_is_gpu for more details. Note that we believe that this scheme could break down in the context of containers, where the initial process executed in a container has pid 1 (in its own pid namespace). For instance, if you were to execute a ROCm program in a container, then spawn a GDB in that container and attach to the process, it will likely not work. This is a known limitation. A workaround for this is to have a dummy process (like a shell) fork and execute the program of interest. The amd-dbgapi target watches native inferiors, and "attaches" to them using amd_dbgapi_process_attach, which gives it a notifier fd that is registered in the event loop (see enable_amd_dbgapi). Note that this isn't the same "attach" as in PTRACE_ATTACH, but being ptrace-attached is a precondition for amd_dbgapi_process_attach to work. When the debugged process enables the ROCm runtime, the amd-dbgapi target gets notified through that fd, and pushes itself on the target stack of the inferior. The amd-dbgapi target is then able to intercept target_ops calls. If the debugged process disables the ROCm runtime, the amd-dbgapi target unpushes itself from the target stack. This way, the amd-dbgapi target's footprint stays minimal when debugging a process that doesn't use the AMD ROCm platform, it does not intercept target calls. The amd-dbgapi library is found using pkg-config. Since enabling support for the amdgpu architecture (amdgpu-tdep.c) depends on the amd-dbgapi library being present, we have the following logic for the interaction with --target and --enable-targets: - if the user explicitly asks for amdgcn support with --target=amdgcn-*-* or --enable-targets=amdgcn-*-*, we probe for the amd-dbgapi and fail if not found - if the user uses --enable-targets=all, we probe for amd-dbgapi, enable amdgcn support if found, disable amdgcn support if not found - if the user uses --enable-targets=all and --with-amd-dbgapi=yes, we probe for amd-dbgapi, enable amdgcn if found and fail if not found - if the user uses --enable-targets=all and --with-amd-dbgapi=no, we do not probe for amd-dbgapi, disable amdgcn support - otherwise, amd-dbgapi is not probed for and support for amdgcn is not enabled Finally, a simple test is included. It only tests hitting a breakpoint in device code and resuming execution, pretty much like the example shown above. [1] https://docs.amd.com/category/ROCm_v5.4 [2] https://docs.amd.com/bundle/HIP-Programming-Guide-v5.4 [3] https://en.wikipedia.org/wiki/Single_instruction,_multiple_threads [4] https://docs.amd.com/bundle/ROCDebugger-API-Guide-v5.4 Change-Id: I591edca98b8927b1e49e4b0abe4e304765fed9ee Co-Authored-By: Zoran Zaric <zoran.zaric@amd.com> Co-Authored-By: Laurent Morichetti <laurent.morichetti@amd.com> Co-Authored-By: Tony Tye <Tony.Tye@amd.com> Co-Authored-By: Lancelot SIX <lancelot.six@amd.com> Co-Authored-By: Pedro Alves <pedro@palves.net>
2023-01-11Set _WIN32_WINNT in common.m4 configure checkTom Tromey1-1/+11
GCC recently added support for the Windows thread model, enabling libstdc++ to support Windows natively. However, this supporrt requires a version of Windows later than the minimum version that is supported by GDB. PR build/29966 points out that the GDB configure test for std::thread does not work in this situation, because _WIN32_WINNT is not defined in test program, and so <thread> seems to be fine. This patch is an attempt to fix the problem, by using the same setting for _WIN32_WINNT at configure time as is used at build time. I don't have access to one of the older systems so I don't think I can truly test this. I did do a mingw cross build, though. I'm going to ask the bug reporter to test it. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29966
2023-01-05gdbsupport: move libxxhash configure check to gdbsupportSimon Marchi1-514/+514
The following patch moves the fast_hash function, which uses libxxhash, to gdbsupport. Move the libxxhash configure check to gdbsupport (and transitively to gdbserver). Change-Id: I242499e50c8cd6fe9f51e6e92dc53a1b3daaa96e Approved-By: Andrew Burgess <aburgess@redhat.com>
2022-12-21Use toplevel configure for GMP and MPFR for gdbAndrew Pinski1-1006/+8
This patch uses the toplevel configure parts for GMP/MPFR for gdb. The only thing is that gdb now requires MPFR for building. Before it was a recommended but not required library. Also this allows building of GMP and MPFR with the toplevel directory just like how it is done for GCC. We now error out in the toplevel configure of the version of GMP and MPFR that is wrong. OK after GDB 13 branches? Build gdb 3 ways: with GMP and MPFR in the toplevel (static library used at that point for both) With only MPFR in the toplevel (GMP distro library used and MPFR built from source) With neither GMP and MPFR in the toplevel (distro libraries used) Changes from v1: * Updated gdb/README and gdb/doc/gdb.texinfo. * Regenerated using unmodified autoconf-2.69 Thanks, Andrew Pinski ChangeLog: * Makefile.def: Add configure-gdb dependencies on all-gmp and all-mpfr. * configure.ac: Split out MPC checking from MPFR. Require GMP and MPFR if the gdb directory exist. * Makefile.in: Regenerate. * configure: Regenerate. gdb/ChangeLog: PR bug/28500 * configure.ac: Remove AC_LIB_HAVE_LINKFLAGS for gmp and mpfr. Use GMPLIBS and GMPINC which is provided by the toplevel configure. * Makefile.in (LIBGMP, LIBMPFR): Remove. (GMPLIBS, GMPINC): Add definition. (INTERNAL_CFLAGS_BASE): Add GMPINC. (CLIBS): Exchange LIBMPFR and LIBGMP for GMPLIBS. * target-float.c: Make the code conditional on HAVE_LIBMPFR unconditional. * top.c: Remove code checking HAVE_LIBMPFR. * configure: Regenerate. * config.in: Regenerate. * README: Update GMP/MPFR section of the config options. * doc/gdb.texinfo: Likewise. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28500
2022-11-15gdb/configure: regenerateJose E. Marchesi1-2/+4
The commit bbaabc767a4293492817a0840819aef2768cce90 introduced an incorrect thunk for the `configure' script. This patch regenerates configure by calling autoreconf.
2022-11-15gdb: use libtool in GDB_AC_CHECK_BFDJose E. Marchesi1-8/+1644
The GDB_AC_CHECK_BFD macro defined in gdb/acinclude.m4 uses the AC_LINK_IFELSE autoconf macro in order to link a simple program to check features of libbfd. If libbfd's link dependencies change, it was necessary to reflect them either in the definition of the macro, or as a consequence of checking for them with an autoconf macro resulting in an addition to LIBS. This patch modifies the definition of the GDB_CHECK_BFD macro in order to use libtool to perform the test link. This makes it possible to not have to list dependencies of libbfd (which are indirect to GDB) at all. After this patch: configure:28553: checking for ELF support in BFD configure:28573: ./libtool --quiet --mode=link gcc -o conftest \ -I../../gdb/../include -I../bfd \ -I../../gdb/../bfd -g -O2 \ -L../bfd -L../libiberty conftest.c -lbfd -liberty \ -lncursesw -lm -ldl >&5 configure:28573: $? = 0 configure:28583: result: yes Tests performed: - Configure --with-system-zlib and --without-system-zlib. - Check link dependencies of installed GDB with both --enable-shared and --disable-shared. - Run installed GDB in both cases. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-11-07gdb: link executables with libtoolJose E. Marchesi1-198/+10866
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 objects libbfd.so, libopcodes.so and libctf.so are 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. No regressions found. - 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 Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-11-07configure: require libzstd >= 1.4.0Christophe Lyon1-10/+10
gas uses ZSTD_compressStream2 which is only available with libzstd >= 1.4.0, leading to build errors when an older version is installed. This patch updates the check libzstd presence to check its version is >= 1.4.0. However, since gas seems to be the only component requiring such a recent version this may imply that we disable ZSTD support for all components although some would still benefit from an older version. I ran 'autoreconf -f' in all directories containing a configure.ac file, using vanilla autoconf-2.69 and automake-1.15.1. I noticed several errors from autoheader in readline, as well as warnings in intl, but they are unrelated to this patch. This should fix some of the buildbots. OK for trunk? Thanks, Christophe
2022-09-28Fix GDB build: ELF support check & -lzstdPedro Alves1-4/+4
GDB fails to build for me, on Ubuntu 20.04. I get: ... CXXLD gdb /usr/bin/ld: linux-tdep.o: in function `linux_corefile_thread(thread_info*, linux_corefile_thread_data*)': /home/pedro/gdb/binutils-gdb/src/gdb/linux-tdep.c:1831: undefined reference to `gcore_elf_build_thread_register_notes(gdbarch*, thread_info*, gdb_signal, bfd*, std::unique_ptr<char, gdb::xfree_deleter<char> >*, int*)' /usr/bin/ld: linux-tdep.o: in function `linux_make_corefile_notes(gdbarch*, bfd*, int*)': /home/pedro/gdb/binutils-gdb/src/gdb/linux-tdep.c:2117: undefined reference to `gcore_elf_make_tdesc_note(bfd*, std::unique_ptr<char, gdb::xfree_deleter<char> >*, int*)' collect2: error: ld returned 1 exit status make[2]: *** [Makefile:2149: gdb] Error 1 make[2]: Leaving directory '/home/pedro/gdb/binutils-gdb/build/gdb' make[1]: *** [Makefile:11847: all-gdb] Error 2 make[1]: Leaving directory '/home/pedro/gdb/binutils-gdb/build' make: *** [Makefile:1004: all] Error 2 Those undefined functions exist in gdb/gcore-elf.c, which is only included in the build if GDB's configure thinks that the target you're configuring for is an ELF target. GDB's configure thinks my system isn't ELF, which is incorrect. For the ELF support check, gdb/config.log shows: configure:17387: checking for ELF support in BFD configure:17407: gcc -o conftest -I/home/pedro/gdb/binutils-gdb/src/gdb/../include -I../bfd -I/home/pedro/gdb/binutils-gdb/src/gdb/../bfd -g3 -O0 -L../bfd -L../libiberty -lzstd conftest.c -lbfd -liberty -lz -lncursesw -lm -ldl >&5 /usr/bin/ld: ../bfd/libbfd.a(compress.o): in function `decompress_contents': /home/pedro/gdb/binutils-gdb/src/bfd/compress.c:42: undefined reference to `ZSTD_decompress' /usr/bin/ld: /home/pedro/gdb/binutils-gdb/src/bfd/compress.c:44: undefined reference to `ZSTD_isError' /usr/bin/ld: ../bfd/libbfd.a(compress.o): in function `bfd_compress_section_contents': /home/pedro/gdb/binutils-gdb/src/bfd/compress.c:195: undefined reference to `ZSTD_compress' /usr/bin/ld: /home/pedro/gdb/binutils-gdb/src/bfd/compress.c:198: undefined reference to `ZSTD_isError' collect2: error: ld returned 1 exit status configure:17407: $? = 1 ... configure:17417: result: no Note how above, in the gcc command line, "-lzstd" appears before "-lbfd". That explain the link failure. It should appear after, like -lz does. This commit fixes it, by moving ZSTD_LIBS from LDFLAGS to LIBS, next to -lz, in GDB_AC_CHECK_BFD, and regenerating gdb/configure. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29630 Change-Id: I1f4128dde634e8ea04c9002904f1005a8b3a6863
2022-09-28Renenerate {gdb,gdbserver}/configurePedro Alves1-2/+2
Pick up config/lib-ld.m4 changes from: commit 67d1991b785bdfef1d70cddfa0202b99b43ccce9 Author: Alan Modra <amodra@gmail.com> AuthorDate: Wed Sep 28 13:37:31 2022 +0930 Commit: Alan Modra <amodra@gmail.com> CommitDate: Wed Sep 28 13:37:31 2022 +0930 egrep in binutils Change-Id: Ifc84d30f1fca015e80bafa80f9a35616b0077220
2022-09-26binutils, gdb: support zstd compressed debug sectionsFangrui Song1-3/+134
PR29397 PR29563: Add new configure option --with-zstd which defaults to auto. If pkgconfig/libzstd.pc is found, define HAVE_ZSTD and support zstd compressed debug sections for most tools. * bfd: for addr2line, objdump --dwarf, gdb, etc * gas: support --compress-debug-sections=zstd * ld: support ELFCOMPRESS_ZSTD input and --compress-debug-sections=zstd * objcopy: support ELFCOMPRESS_ZSTD input for --decompress-debug-sections and --compress-debug-sections=zstd * gdb: support ELFCOMPRESS_ZSTD input. The bfd change references zstd symbols, so gdb has to link against -lzstd in this patch. If zstd is not supported, ELFCOMPRESS_ZSTD input triggers an error. We can avoid HAVE_ZSTD if binutils-gdb imports zstd/ like zlib/, but this is too heavyweight, so don't do it for now. ``` % ld/ld-new a.o ld/ld-new: a.o: section .debug_abbrev is compressed with zstd, but BFD is not built with zstd support ... % ld/ld-new a.o --compress-debug-sections=zstd ld/ld-new: --compress-debug-sections=zstd: ld is not built with zstd support % binutils/objcopy --compress-debug-sections=zstd a.o b.o binutils/objcopy: --compress-debug-sections=zstd: binutils is not built with zstd support % binutils/objcopy b.o --decompress-debug-sections binutils/objcopy: zstd.o: section .debug_abbrev is compressed with zstd, but BFD is not built with zstd support ... ```
2022-08-26gdb, gdbsupport: configure: factor out yes/no/auto value checkingSimon Marchi1-38/+58
Factor out the code that checks that a value is yes/no or yes/no/auto. Add two macros to gdbsupport/common.m4 and use them in gdb/configure.ac I inspected the changes to configure. Other than whitespace changes, we have some benign changes to the error messages (one of them had an error actually). There are changes to the --enable-source-highlight and --enable-libbacktrace handling, but setting enable_source_highlight / enable_libbacktrace was not really useful anyway, they already had the right value. Change-Id: I92587aec36874309e1605e2d60244649f09a757a
generated by cgit v1.1 at 2025-03-15 07:38:13 +0000