aboutsummaryrefslogtreecommitdiff
path: root/gdb/configure
AgeCommit message (Collapse)AuthorFilesLines
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
2022-07-18gdb/python: look for python, then python 3 at configure timeAndrew Burgess1-3/+9
It is possible that a system might have a python3 executable, but no python executable. For example, on my Fedora system the python2 package provides /usr/bin/python2, the python3 package provides /usr/bin/python3, and the python-unversioned-command package provides /usr/bin/python, which picks between python2 and python3. It is quite possible to only have python3 available on a system. Currently, when GDB configures, it looks for a 'python' executable. If non is found then GDB will be built without python support. Or the user needs to configure using --with-python=/usr/bin/python3. This commit updates GDB's configure.ac script to first look for 'python', and then 'python3'. Now, on a system that only has a python3 executable, GDB will automatically find, and use that in order to provide python support, no user supplied configure arguments are needed. I've tested this on my local machine by removing the python-unversioned-command package, confirming that there is no longer a 'python' executable in my $PATH, and then rebuilding GDB from scratch. GDB with this patch has python support.
2022-06-13gdb: don't use bashism in configure testSam James1-1/+1
Results in configure output like: ``` checking for X... no /var/tmp/portage/sys-devel/gdb-12.1/work/gdb-12.1/gdb/configure: 18837: test: yes: unexpected operator checking whether to use babeltrace... auto ``` ... when /bin/sh is provided by a POSIX-compliant shell, like dash, instead of bash.
2022-04-15Remove WITH_SIM defineTom Tromey1-3/+0
Since score-tdep.c was removed, the WITH_SIM define is not used in gdb. This patch removes it. Note that re-running autoheader shows a separate change that was missed. I've kept it in this patch to avoid extra work.
2022-04-14Let std::thread check pass even without pthreadsTom Tromey1-10/+9
Currently, the configure check for std::thread relies on pthreads existing. However, this means that if std::thread is implemented for a non-pthreads host, then the check will yield the wrong answer. This happened in AdaCore internal builds. Here, we have this GCC patch: https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ... which adds mingw support to GCC's gthreads implementation, and also to std::thread. This configure change fixes this problem and enables threading for gdb.
2022-03-23gdb/python: remove Python 2 supportSimon Marchi1-74/+4
New in this version: - Add a PY_MAJOR_VERSION check in configure.ac / AC_TRY_LIBPYTHON. If the user passes --with-python=python2, this will cause a configure failure saying that GDB only supports Python 3. Support for Python 2 is a maintenance burden for any patches touching Python support. Among others, the differences between Python 2 and 3 string and integer types are subtle. It requires a lot of effort and thinking to get something that behaves correctly on both. And that's if the author and reviewer of the patch even remember to test with Python 2. See this thread for an example: https://sourceware.org/pipermail/gdb-patches/2021-December/184260.html So, remove Python 2 support. Update the documentation to state that GDB can be built against Python 3 (as opposed to Python 2 or 3). Update all the spots that use: - sys.version_info - IS_PY3K - PY_MAJOR_VERSION - gdb_py_is_py3k ... to only keep the Python 3 portions and drop the use of some now-removed compatibility macros. I did not update the configure script more than just removing the explicit references to Python 2. We could maybe do more there, like check the Python version and reject it if that version is not supported. Otherwise (with this patch), things will only fail at compile time, so it won't really be clear to the user that they are trying to use an unsupported Python version. But I'm a bit lost in the configure code that checks for Python, so I kept that for later. Change-Id: I75b0f79c148afbe3c07ac664cfa9cade052c0c62
2022-03-02configure: Stop checking for PT_GETXMMREGS.John Baldwin1-37/+0
This request is present on all modern *BSD/i386 systems (those released since mid-2006), and the *BSD/i386 targets now assume it is present unconditionally.
2022-02-22gdb: fix detection of compilation and linking flags for source-highlightRuslan Kabatsayev1-6/+6
Currently there are two problems with the detection of source-highlight via pkg-config in GDB's configure script: 1. The LDFLAGS variable is used to pass the 'pkg-config --libs' output to AC_LINK_IFELSE, which results in the "-L/some/path -lsource-highlight" preceding the conftest.cpp, which can result in a failure to find symbols referenced in conftest.cpp, if the linker is using --as-needed by default. 2. The CFLAGS variable is used to pass the 'pkg-config --cflags' output to AC_LINK_IFELSE. However, as the current language is C++, AC_LINK_IFELSE will actuall use CXXFLAGS, not CFLAGS, so any flags returned from pkg-config will not be seen. This patch fixes both of these mistakes, allowing GDB to correctly configure and build using source-highlight installed into a custom prefix, e.g. ~/opt/gdb-git (because the system version of source-highlight is too old).
2022-01-13gdb: don't use -Wmissing-prototypes with g++Andrew Burgess1-1/+65
This commit aims to not make use of -Wmissing-prototypes when compiling with g++. Use of -Wmissing-prototypes was added with this commit: commit a0761e34f054767de6d6389929d27e9015fb299b Date: Wed Mar 11 15:15:12 2020 -0400 gdb: enable -Wmissing-prototypes warning Because clang can provide helpful warnings with this flag. Unfortunately, g++ doesn't accept this flag, and will give this warning: cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++ In theory the fact that this flag is not supported should be detected by the configure check in gdbsupport/warning.m4, but for users of ccache, this check doesn't work due to a long standing ccache issue: https://github.com/ccache/ccache/issues/738 The ccache problem is that -W... options are reordered on the command line, and so -Wmissing-prototypes is seen before -Werror. Usually this doesn't matter, but the above warning (about the flag not being valid) is issued before the -Werror flag is processed, and so is not fatal. There have been two previous attempts to fix this that I'm aware of. The first is: https://sourceware.org/pipermail/gdb-patches/2021-September/182148.html In this attempt, instead of just relying on a compile to check if a flag is valid, the proposal was to both compile and link. As linking doesn't go through ccache, we don't suffer from the argument reordering problem, and the link phase will correctly fail when using -Wmissing-prototypes with g++. The configure script will then disable the use of this flag. This approach was rejected, and the suggestion was to only add the -Wmissing-prototypes flag if we are compiling with gcc. The second attempt, attempts this approach, and can be found here: https://sourceware.org/pipermail/gdb-patches/2021-November/183076.html This attempt only adds the -Wmissing-prototypes flag is the value of GCC is not 'yes'. This feels like it is doing the right thing, unfortunately, the GCC flag is really a 'is gcc like' flag, not a strict, is gcc check. As such, GCC is set to 'yes' for clang, which would mean the flag was not included for clang or gcc. The entire point of the original commit was to add this flag for clang, so clearly the second attempt is not sufficient either. In this new attempt I have added gdbsupport/compiler-type.m4, this file defines AM_GDB_COMPILER_TYPE. This macro sets the variable GDB_COMPILER_TYPE to either 'gcc', 'clang', or 'unknown'. In future the list of values might be extended to cover other compilers, if this is ever useful. I've then modified gdbsupport/warning.m4 to only add the problematic -Wmissing-prototypes flag if GDB_COMPILER_TYPE is not 'gcc'. I've tested this with both gcc and clang and see the expected results, gcc no longer attempts to use the -Wmissing-prototypes flag, while clang continues to use it. When compiling using ccache, I am no longer seeing the warning.
2022-01-01unify 64-bit bfd checksMike Frysinger1-56/+67
Move the 64-bit bfd logic out of bfd/configure.ac and into bfd64.m4 under config so it can be shared between all the other subdirs. This replaces want64 with enable_64_bit_bfd which was already being declared, but not used directly.
2021-12-15New --enable-threading configure option to control use of threads in ↵Luis Machado1-1/+23
GDB/GDBserver Add the --enable-threading configure option so multithreading can be disabled at configure time. This is useful for statically-linked builds of GDB/GDBserver, since the thread library doesn't play well with that setup. If you try to run a statically-linked GDB built with threading, it will crash when setting up the number of worker threads. This new option is also convenient when debugging GDB in a system with lots of threads, where the thread discovery code in GDB will emit too many messages, like so: [New Thread 0xfffff74d3a50 (LWP 2625599)] If you have X threads, that message will be repeated X times. The default for --enable-threading is "yes".
2021-11-27gdb: fix typos in configureSimon Marchi1-4/+4
The variable names used to restore CFLAGS and LDFLAGS here don't quite match the names used above, resulting in losing the original CFLAGS and LDFLAGS. Fix that. Change-Id: I9cc2c3b48b1dc30c31a7143563c893fd6f426a0a
2021-11-23configure.ac: Check for the readline.h explicitlyAlexandra Hájková1-0/+17
When readline development package is missing make fails with "configure: error: system readline is not new enough" which might be confusing. This patch checks for the readline.h explicitly and makes make to warn about the missing package.
2021-11-20[gdb/build] Check if libsource-highlight is usableTom de Vries1-49/+109
When building gdb with g++ 4.8.5, I ran into: ... ld: source-cache.o: in function `source_cache::ensure(symtab*)': source-cache.c:207: undefined reference to \ srchilite::SourceHighlight::SourceHighlight(std::string const&) ... [ I configured gdb without explicit settings related to source-highlight, so we're excercising the enable_source_highlight=auto scenario. ] The problem is that: - the source-highlight library is build with system compiler g++ 7.5.0 which uses the new libstdc++ library abi (see https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html ) - gdb is build using g++ 4.8.5 which uses the old abi. [ There's a compatibility macro _GLIBCXX_USE_CXX11_ABI, but that doesn't work for this case. Instead, it enables the opposite case where the source-highlight library is build with g++ 4.8.5 and gdb is build with g++ 7.5.0. ] Fix this by checking whether the source-highlight library is usable during configuration. In the enable_source_highlight=auto scenario, this allows the build to skip the unusable library and finish successfully. In the enable_source_highlight=yes scenario, this allows the build to error out earlier. Tested on x86_64-linux.
2021-11-09Fix build on rhES5Tom Tromey1-0/+16
The rhES5 build failed due to an upstream import a while back. The bug here is that, while the 'personality' function exists, ADDR_NO_RANDOMIZE is only defined in <linux/personality.h>, not <sys/personality.h>. However, <linux/personality.h> does not declare the 'personality' function, and <sys/personality.h> and <linux/personality.h> cannot both be included. This patch restores one of the removed configure checks and updates the code to check it. We had this as a local patch at AdaCore, because it seemed like there was no interest upstream. However, now it turns out that this fixes PR build/28555, so I'm sending it now.
generated by cgit v1.1 at 2024-11-25 00:59:55 +0000