aboutsummaryrefslogtreecommitdiff
path: root/gdb/configure.ac
AgeCommit message (Collapse)AuthorFilesLines
2023-11-30[gdb/build] Fix adding -DNDEBUG to python flags of release buildTom de Vries1-1/+2
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-10-28gdb/gdbsupport/gdbserver: Require c++17Lancelot Six1-2/+2
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-12Move -lsocket check to common.m4Tom Tromey1-5/+2
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-0/+8
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-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-02-23gdb: remove --disable-gdbmi configure optionSimon Marchi1-14/+0
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-5/+5
'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-0/+3
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/+1
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-0/+52
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-05gdbsupport: move libxxhash configure check to gdbsupportSimon Marchi1-23/+0
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>
2023-01-01Update copyright year range in header of all files managed by GDBJoel Brobecker1-1/+1
This commit is the result of running the gdb/copyright.py script, which automated the update of the copyright year range for all source files managed by the GDB project to be updated to include year 2023.
2022-12-21Use toplevel configure for GMP and MPFR for gdbAndrew Pinski1-29/+2
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: use libtool in GDB_AC_CHECK_BFDJose E. Marchesi1-0/+3
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-9/+8
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-09-26binutils, gdb: support zstd compressed debug sectionsFangrui Song1-1/+3
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-55/+29
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-1/+2
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-1/+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-03-23gdb/python: remove Python 2 supportSimon Marchi1-12/+6
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-20/+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-0/+1
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-26/+3
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.
2022-01-01Automatic Copyright Year update after running gdb/copyright.pyJoel Brobecker1-1/+1
This commit brings all the changes made by running gdb/copyright.py as per GDB's Start of New Year Procedure. For the avoidance of doubt, all changes in this commits were performed by the script.
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/+4
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-5/+42
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-10-19Fix format_pieces selftest on WindowsTom Tromey1-21/+0
The format_pieces selftest currently fails on Windows hosts. The selftest doesn't handle the "%ll" -> "%I64" rewrite that the formatter may perform, but also gdbsupport was missing a configure check for PRINTF_HAS_LONG_LONG. This patch fixes both issues.
2021-09-28gdb: use libbacktrace to create a better backtrace for fatal signalsAndrew Burgess1-0/+23
GDB recently gained the ability to print a backtrace when a fatal signal is encountered. This backtrace is produced using the backtrace and backtrace_symbols_fd API available in glibc. However, in order for this API to actually map addresses to symbol names it is required that the application (GDB) be compiled with -rdynamic, which GDB is not by default. As a result, the backtrace produced often looks like this: Fatal signal: Bus error ----- Backtrace ----- ./gdb/gdb[0x80ec00] ./gdb/gdb[0x80ed56] /lib64/libc.so.6(+0x3c6b0)[0x7fc2ce1936b0] /lib64/libc.so.6(__poll+0x4f)[0x7fc2ce24da5f] ./gdb/gdb[0x15495ba] ./gdb/gdb[0x15489b8] ./gdb/gdb[0x9b794d] ./gdb/gdb[0x9b7a6d] ./gdb/gdb[0x9b943b] ./gdb/gdb[0x9b94a1] ./gdb/gdb[0x4175dd] /lib64/libc.so.6(__libc_start_main+0xf3)[0x7fc2ce17e1a3] ./gdb/gdb[0x4174de] --------------------- This is OK if you have access to the exact same build of GDB, you can manually map the addresses back to symbols, however, it is next to useless if all you have is a backtrace copied into a bug report. GCC uses libbacktrace for printing a backtrace when it encounters an error. In recent commits I added this library into the binutils-gdb repository, and in this commit I allow this library to be used by GDB. Now (when GDB is compiled with debug information) the backtrace looks like this: ----- Backtrace ----- 0x80ee08 gdb_internal_backtrace ../../src/gdb/event-top.c:989 0x80ef0b handle_fatal_signal ../../src/gdb/event-top.c:1036 0x7f24539dd6af ??? 0x7f2453a97a5f ??? 0x154976f gdb_wait_for_event ../../src/gdbsupport/event-loop.cc:613 0x1548b6d _Z16gdb_do_one_eventv ../../src/gdbsupport/event-loop.cc:237 0x9b7b02 start_event_loop ../../src/gdb/main.c:421 0x9b7c22 captured_command_loop ../../src/gdb/main.c:481 0x9b95f0 captured_main ../../src/gdb/main.c:1353 0x9b9656 _Z8gdb_mainP18captured_main_args ../../src/gdb/main.c:1368 0x4175ec main ../../src/gdb/gdb.c:32 --------------------- Which seems much more useful. Use of libbacktrace is optional. If GDB is configured with --disable-libbacktrace then the libbacktrace directory will not be built, and GDB will not try to use this library. In this case GDB would try to use the old backtrace and backtrace_symbols_fd API. All of the functions related to writing the backtrace of GDB itself have been moved into the new files gdb/by-utils.{c,h}.
2021-08-11gdb: print backtrace on fatal SIGSEGVAndrew Burgess1-0/+22
This commit adds a new maintenance feature, the ability to print a (limited) backtrace if GDB dies due to a fatal signal. The backtrace is produced using the backtrace and backtrace_symbols_fd functions which are declared in the execinfo.h header, and both of which are async signal safe. A configure check has been added to check for these features, if they are not available then the new code is not compiled into GDB and the backtrace will not be printed. The motivation for this new feature is to aid in debugging GDB in situations where GDB has crashed at a users site, but the user is reluctant to share core files, possibly due to concerns about what might be in the memory image within the core file. Such a user might be happy to share a simple backtrace that was written to stderr. The production of the backtrace is on by default, but can switched off using the new commands: maintenance set backtrace-on-fatal-signal on|off maintenance show backtrace-on-fatal-signal Right now, I have hooked this feature in to GDB's existing handling of SIGSEGV only, but this will be extended to more signals in a later commit. One additional change I have made in this commit is that, when we decide GDB should terminate due to the fatal signal, we now raise the same fatal signal rather than raising SIGABRT. Currently, this is only effecting our handling of SIGSEGV. So, previously, if GDB hit a SEGV then we would terminate GDB with a SIGABRT. After this commit we will terminate GDB with a SIGSEGV. This feels like an improvement to me, we should still get a core dump, but in many shells, the user will see a more specific message once GDB exits, in bash for example "Segmentation fault" rather than "Aborted". Finally then, here is an example of the output a user would see if GDB should hit an internal SIGSEGV: Fatal signal: Segmentation fault ----- Backtrace ----- ./gdb/gdb[0x8078e6] ./gdb/gdb[0x807b20] /lib64/libpthread.so.0(+0x14b20)[0x7f6648c92b20] /lib64/libc.so.6(__poll+0x4f)[0x7f66484d3a5f] ./gdb/gdb[0x1540f4c] ./gdb/gdb[0x154034a] ./gdb/gdb[0x9b002d] ./gdb/gdb[0x9b014d] ./gdb/gdb[0x9b1aa6] ./gdb/gdb[0x9b1b0c] ./gdb/gdb[0x41756d] /lib64/libc.so.6(__libc_start_main+0xf3)[0x7f66484041a3] ./gdb/gdb[0x41746e] --------------------- A fatal error internal to GDB has been detected, further debugging is not possible. GDB will now terminate. This is a bug, please report it. For instructions, see: <https://www.gnu.org/software/gdb/bugs/>. Segmentation fault (core dumped) It is disappointing that backtrace_symbols_fd does not actually map the addresses back to symbols, this appears, in part, to be due to GDB not being built with -rdynamic as the manual page for backtrace_symbols_fd suggests, however, even when I do add -rdynamic to the build of GDB I only see symbols for some addresses. We could potentially look at alternative libraries to provide the backtrace (e.g. libunwind) however, the solution presented here, which is available as part of glibc is probably a good baseline from which we might improve things in future.
2021-07-06gdb/testsuite: restore configure scriptSimon Marchi1-34/+1
Commit f99d1d37496f ("Remove gdb/testsuite/configure") removed gdb/testsuite/configure, as anything gdb/testsuite/configure did could be done by gdb/configure. There is however one use case that popped up when this changed propagated to downstream consumers, to run the testsuite on an already built GDB. In the workflow of ROCm-GDB at AMD, a GDB package is built in a CI job. This GDB package is then tested on different machines / hardware configurations as part of other CI jobs. To achieve this, those CI jobs only configure the testsuite directory and run "make check" with an appropriate board file. In light of this use case, the way I see it is that gdb/testsuite could be considered its own project. It could be stored in a completely different repo if we want to, it just happens to be stored inside gdb/. Since the only downside of having gdb/testsuite/configure is that it takes a few more seconds to run, but on the other hand it's quite useful for some people, I propose re-adding it. In a sense, this is revert of f99d1d37496f, but it's not a direct git-revert, as some things have changed since. gdb/ChangeLog: * configure.ac: Remove things that were moved from testsuite/configure.ac. * configure: Re-generate. gdb/testsuite/ChangeLog: * configure.ac: Restore. * configure: Re-generate. * aclocal.m4: Re-generate. * Makefile.in (distclean): Add config.status. (Makefile): Adjust paths. (lib/pdtrace): Adjust paths. (config.status): Add. Change-Id: Ic38c79485e1835712d9c99649c9dfb59667254f1
2021-06-19gdb/gdbserver: switch to AC_CONFIG_MACRO_DIRSMike Frysinger1-2/+1
These dirs don't use automake, so use AC_CONFIG_MACRO_DIRS to specify ../config as a search dir for m4 macros. This allows removal of a lot of hand-written m4_include's from acinclude.m4 files, and simplifies use of `aclocal` or `autoreconf` as manual -I is not needed.
2021-06-14fbsd nat: Disable address space randomization when requested.John Baldwin1-1/+1
Use procctl(2) with PROC_ASLR_CTL to disable address space randomization in the current gdb process before forking a child process for a new inferior when address space randomization is disabled. gdb/ChangeLog: * configure.ac: Check for <sys/procctl.h>. * config.in, configure: Regenerate. * fbsd-nat.c: Include <sys/procctl.h> if present. [PROC_ASLR_CTL] (maybe_disable_address_space_randomization): New. (fbsd_nat_target::create_inferior) (fbsd_nat_target::supports_disable_randomization): New. * fbsd-nat.h (fbsd_nat_target::create_inferior) (fbsd_nat_target::supports_disable_randomization): New.
2021-06-05Use ACX_NONCANONICAL_TARGET in gdb/configureTom Tromey1-0/+2
Shahab Vahedi pointed out that the patch to remove gdb/testsuite/configure regressed the site.exp creation a bit -- it left an unresolved configure substitution. Andrew Burgess pointed out that the patch removed the call to ACX_NONCANONICAL_TARGET, which caused this problem. This patch adds ACX_NONCANONICAL_TARGET to gdb's configure, and fixes the bug. gdb/ChangeLog 2021-06-05 Tom Tromey <tromey@adacore.com> * configure: Rebuild. * configure.ac: Add ACX_NONCANONICAL_TARGET.
2021-06-01Clean up gdb's --enable-sharedTom Tromey1-1/+1
The old testsuite configure did not use AS_HELP_STRING, and it had a typo in the help for --enable-shared. This patch fixes these problems. gdb/ChangeLog 2021-06-01 Tom Tromey <tromey@adacore.com> * configure: Rebuild. * configure.ac: Use AS_HELP_STRING for enable-shared. Fix typo.
2021-06-01Remove gdb/testsuite/configureTom Tromey1-2/+34
I didn't see a strong reason to have a separate configure script in gdb/testsuite, so this patch removes it. The few relevant configury bits are moved into gdb's configure script. Some of the old testsuite/configure script (e.g., the header check) is dead code. This also adds a Makefile rule to rebuild lib/pdtrace. This was missing from the old code. 'read1' is now a dependency of check-read1, rather than extra code at configure time. Finally, the old "ENABLE_LIBCTF" subst in gdb/configure was not used; nor was the variable defined, so this was always empty. However, the lower-case variant was used by the testsuite, so this patch renames the subst. gdb/ChangeLog 2021-06-01 Tom Tromey <tromey@adacore.com> * configure.ac: Copy some code from testsuite/configure.ac. (enable_libctf): Subst this, not ENABLE_LIBCTF. * configure: Rebuild. gdb/testsuite/ChangeLog 2021-06-01 Tom Tromey <tromey@adacore.com> * aclocal.m4, configure.ac, configure: Remove. * Makefile.in (EXTRA_RULES): Remove. ($(abs_builddir)/site.exp site.exp): Don't depend on config.status. (distclean maintainer-clean realclean, Makefile): Update. (config.status): Remove target. (lib/pdtrace): New target. (all): Don't depend on EXTRA_RULES. (check-read1): Depend on read1.so, expect-read1.
2021-04-21[gdb/build] Hardcode --with-included-regexTom de Vries1-33/+0
Currently gdb has a configure option: ... $ ./src/gdb/configure --help ... --without-included-regex don't use included regex; this is the default on systems with version 2 of the GNU C library (use with caution on other system) ... The configure option controls config.h macro USE_INCLUDED_REGEX, which is used in gdb/gdb_regex.h to choose between: - using regex from libiberty (which is included in the binutils-gdb.git repo, hence the 'included' in USE_INCLUDED_REGEX), or - using regex.h. In the former case, the symbol regcomp is remapped to a symbol xregcomp, which is then provided by libiberty. In the latter case, the symbol regcomp is resolved at runtime, usually binding to libc. However, there is no mechanism in place to enforce this. PR27681 is an example of where that causes problems. On openSUSE Tumbleweed, the ncurses package got the --with-pcre2 configure switch enabled, and solved the resulting dependencies using: ... $ cat /usr/lib64/libncursesw.so /* GNU ld script */ -INPUT(/lib64/libncursesw.so.6 AS_NEEDED(-ltinfo -ldl)) +INPUT(/lib64/libncursesw.so.6 AS_NEEDED(-ltinfo -ldl -lpcre2-posix -lpcre2-8)) ... This lead to regcomp being bound to libpcre2-posix instead of libc. This causes problems in several ways: - by compiling using regex.h, we've already chosen a specific regex_t implementation, and the one from pcre2-posix is not the same. - in gdb_regex.c we use GNU regex function re_search, which pcre2-posix doesn't provide, so while regcomp binds to pcre2-posix, re_search binds to libc. A note on the latter: it's actually a bug to compile a regex using regcomp and then pass it to re_search. The GNU regex interface requires one to use re_compile_pattern or re_compile_fastmap. But as long we're using one of the GNU regex incarnations in gnulib, glibc or libiberty, we get away with this. The PR could be fixed by adding -lc in a specific position in the link line, to force regcomp to be bound to glibc. But this solution was considered in the discussion in the PR as being brittle, and possibly causing problems elsewhere. Another solution offered was to restrict regex usage to posix, and no longer use the GNU regex API. This however could mean having to reproduce some of that functionality locally, which would mean maintaining the same functionality in more than one place. The solution chosen here, is to hardcode --with-included-regex, that is, using libiberty. The option of using glibc for regex was introduced because glibc became the authorative source for GNU regex, so it offered the possibility to link against a more up-to-date regex version. In that aspect, this patch is a step back. But we have the option of using a more up-to-date regex version as a follow-up step: by using the regex from gnulib. Tested on x86_64-linux. gdb/ChangeLog: 2021-04-21 Tom de Vries <tdevries@suse.de> PR build/27681 * configure.ac: Remove --without-included-regex/--with-included-regex. * config.in: Regenerate. * configure: Regenerate. * gdb_regex.h: Assume USE_INCLUDED_REGEX is defined.
2021-04-15gdb: process early initialization files and command line optionsAndrew Burgess1-0/+3
Adds the ability to process commands at a new phase during GDB's startup. This phase is earlier than the current initialisation file processing, before GDB has produced any output. The number of commands that can be processed at this early stage will be limited, and it is expected that the only commands that would be processed at this stage will relate to some of the fundamentals of how GDB starts up. Currently the only commands that it makes sense to add to this early initialization file are those like 'set style version ....' as the version string is displayed during startup before the standard initialization files are parsed. As such this commit fully resolved bug cli/25956. This commit adds a mechanism to execute these early initialization files from a users HOME directory, as well as some corresponding command line flags for GDB. The early initialization files that GDB will currently check for are ~/.config/gdb/gdbearlyinit (on Linux like systems) or ~/.gdbearlyinit if the former is not found. The output of 'gdb --help' has been extended to include a list of the early initialization files being processed. gdb/ChangeLog: PR cli/25956 * NEWS: Mention new early init files and command line options. * config.in: Regenerate. * configure: Regenerate. * configure.ac: Define GDBEARLYINIT. * main.c (get_earlyinit_files): New function. (enum cmdarg_kind): Add CMDARG_EARLYINIT_FILE and CMDARG_EARLYINIT_COMMAND. (captured_main_1): Add support for new command line flags, and for processing startup files. (print_gdb_help): Include startup files in the output. gdb/doc/ChangeLog: PR cli/25956 * gdb.texinfo (File Options): Mention new command line options. (Startup): Discuss when early init files are processed. (Initialization Files): Add description of early init files. (Output Styling): Update description of 'version' style. (gdb man): Mention early init files. gdb/testsuite/ChangeLog: PR cli/25956 * gdb.base/early-init-file.c: New file. * gdb.base/early-init-file.exp: New file. * lib/gdb-utils.exp (style): Handle style 'none'.
2021-03-05gdb/riscv: introduce bare metal core dump supportAndrew Burgess1-1/+2
This commit adds the ability for bare metal RISC-V target to generate core files from within GDB. The intended use case is that a user will connect to a remote bare metal target, debug up to some error condition, then generate a core file in the normal way using: (gdb) generate-core-file This core file can then be used to revisit the state of the remote target without having to reconnect to the remote target. The core file creation code is split between two new files. In elf-none-tdep.c is code for any architecture with the none ABI (i.e. bare metal) when the BFD library is built with ELF support. In riscv-none-tdep.c are the RISC-V specific parts. This is where the regset and regcache_map_entry structures are defined that control how registers are laid out in the core file. As this file could (in theory at least) be used for a non-ELF bare metal RISC-V target, the calls into elf-none-tdep.c are guarded with '#ifdef HAVE_ELF'. Currently for RISC-V only the x-regs and f-regs (if present) are written out. In future commits I plan to add support for writing out the RISC-V CSRs. The core dump format is based around generating an ELF containing sections for the writable regions of memory that a user could be using. Which regions are dumped rely on GDB's existing common core dumping code, GDB will attempt to figure out the stack and heap as well as copying out writable data sections as identified by the original ELF. Register information is added to the core dump using notes, just as it is for Linux of FreeBSD core dumps. The note types used consist of the 3 basic types you would expect in a OS based core dump, NT_PRPSINFO, NT_PRSTATUS, NT_FPREGSET. The layout of these notes differs slightly (due to field sizes) between RV32 and RV64. Below I describe the data layout for each note. In all cases, all padding fields should be set to zero. Note NT_PRPSINFO is optional. Its data layout is: struct prpsinfo32_t /* For RV32. */ { uint8_t padding[32]; char fname[16]; char psargs[80]; } struct prpsinfo64_t /* For RV64. */ { uint8_t padding[40]; char fname[16]; char psargs[80]; } Field 'fname' - null terminated string consisting of the basename of (up to the fist 15 characters of) the executable. Any additional space should be set to zero. If there's no executable name then this field can be set to all zero. Field 'psargs' - a null terminated string up to 80 characters in length. Any additional space should be filled with zero. This field contains the full executable path and any arguments passed to the executable. If there's nothing sensible to write in this field then fill it with zero. Note NT_PRSTATUS is required, its data layout is: struct prstatus32_t /* For RV32. */ { uint8_t padding_1[12]; uint16_t sig; uint8_t padding_2[10]; uint32_t thread_id; uint8_t padding_3[44]; uint32_t x_regs[32]; uint8_t padding_4[4]; } struct prstatus64_t /* For RV64. */ { uint8_t padding_1[12]; uint16_t sig; uint8_t padding_2[18]; uint32_t thread_id; uint8_t padding_3[76]; uint64_t x_regs[32]; uint8_t padding_4[4]; } Field 'sig' - the signal that stopped this thread. It's implementation defined what this field actually means. Within GDB this will be the signal number that the remote target reports as the stop reason for this thread. Field 'thread_is' - the thread id for this thread. It's implementation defined what this field actually means. Within GDB this will be thread thread-id that is assigned to each remote thread. Field 'x_regs' - at index 0 we store the program counter, and at indices 1 to 31 we store x-registers 1 to 31. x-register 0 is not stored, its value is always zero anyway. Note NT_FPREGSET is optional, its data layout is: fpregset32_t /* For targets with 'F' extension. */ { uint32_t f_regs[32]; uint32_t fcsr; } fpregset64_t /* For targets with 'D' extension . */ { uint64_t f_regs[32]; uint32_t fcsr; } Field 'f_regs' - stores f-registers 0 to 31. Field 'fcsr' - stores the fcsr CSR register, and is always 4-bytes. The rules for ordering the notes is the same as for Linux. The NT_PRSTATUS note must come before any other notes about additional register sets. And for multi-threaded targets all registers for a single thread should be grouped together. This is because only NT_PRSTATUS includes a thread-id, all additional register notes after a NT_PRSTATUS are assumed to belong to the same thread until a different NT_PRSTATUS is seen. gdb/ChangeLog: * Makefile.in (ALL_TARGET_OBS): Add riscv-none-tdep.o. (ALLDEPFILES): Add riscv-none-tdep.c. * configure: Regenerate. * configure.ac (CONFIG_OBS): Add elf-none-tdep.o when BFD has ELF support. * configure.tgt (riscv*-*-*): Include riscv-none-tdep.c. * elf-none-tdep.c: New file. * elf-none-tdep.h: New file. * riscv-none-tdep.c: New file.
2021-03-05gdb: unify parts of the Linux and FreeBSD core dumping codeAndrew Burgess1-1/+1
While reviewing the Linux and FreeBSD core dumping code within GDB for another patch series, I noticed that the code that collects the registers for each thread and writes these into ELF note format is basically identical between Linux and FreeBSD. This commit merges this code and moves it into a new file gcore-elf.c. The function find_signalled_thread is moved from linux-tdep.c to gcore.c despite not being shared. A later commit will make use of this function. I did merge, and then revert a previous version of this patch (commit 82a1fd3a4935 for the original patch and 03642b7189bc for the revert). The problem with the original patch is that it introduced a unconditional dependency between GDB and some ELF specific functions in the BFD library, e.g. elfcore_write_prstatus and elfcore_write_register_note. It was pointed out in this mailing list post: https://sourceware.org/pipermail/gdb-patches/2021-February/175750.html that this change was breaking any build of GDB for non-ELF targets. To confirm this breakage, and to test this new version of GDB I configured and built for the target x86_64-apple-darwin20.3.0. Where the previous version of this patch placed all of the common code into gcore.c, which is included in all builds of GDB, this new patch only places non-ELF specific generic code (i.e. find_signalled_thread) into gcore.c, the ELF specific code is put into the new gcore-elf.c file, which is only included in GDB if BFD has ELF support. The contents of gcore-elf.c are referenced unconditionally from linux-tdep.c and fbsd-tdep.c, this is fine, we previously always assumed that these two targets required ELF support, and we continue to make that assumption after this patch; nothing has changed there. With my previous version of this patch the darwin target mentioned above failed to build, but with the new version, the target builds fine. There are a couple of minor changes to the FreeBSD target after this commit, but I believe that these are changes for the better: (1) For FreeBSD we always used to record the thread-id in the core file by using ptid_t.lwp (). In contrast the Linux code did this: /* For remote targets the LWP may not be available, so use the TID. */ long lwp = ptid.lwp (); if (lwp == 0) lwp = ptid.tid (); Both target now do this: /* The LWP is often not available for bare metal target, in which case use the tid instead. */ if (ptid.lwp_p ()) lwp = ptid.lwp (); else lwp = ptid.tid (); Which is equivalent for Linux, but is a change for FreeBSD. I think that all this means is that in some cases where GDB might have previously recorded a thread-id of 0 for each thread, we might now get something more useful. (2) When collecting the registers for Linux we collected into a zero initialised buffer. By contrast on FreeBSD the buffer is left uninitialised. In the new code the buffer is always zero initialised. I suspect once the registers are copied into the buffer there's probably no gaps left so this makes no difference, but if it does then using zeros rather than random bits of GDB's memory is probably a good thing. Otherwise, there should be no other user visible changes after this commit. Tested this on x86-64/GNU-Linux and x86-64/FreeBSD-12.2 with no regressions. gdb/ChangeLog: * Makefile.in (SFILES): Add gcore-elf.c. (HFILES_NO_SRCDIR): Add gcore-elf.h * configure: Regenerate. * configure.ac: Add gcore-elf.o to CONFIG_OBS if we have ELF support. * fbsd-tdep.c: Add 'gcore-elf.h' include. (struct fbsd_collect_regset_section_cb_data): Delete. (fbsd_collect_regset_section_cb): Delete. (fbsd_collect_thread_registers): Delete. (struct fbsd_corefile_thread_data): Delete. (fbsd_corefile_thread): Delete. (fbsd_make_corefile_notes): Call gcore_elf_build_thread_register_notes instead of the now deleted FreeBSD code. * gcore-elf.c: New file, the content was moved here from linux-tdep.c, functions were renamed and given minor cleanup. * gcore-elf.h: New file. * gcore.c (gcore_find_signalled_thread): Moved here from linux-tdep.c and given a new name. Minor cleanups. * gcore.h (gcore_find_signalled_thread): Declare. * linux-tdep.c: Add 'gcore.h' and 'gcore-elf.h' includes. (struct linux_collect_regset_section_cb_data): Delete. (linux_collect_regset_section_cb): Delete. (linux_collect_thread_registers): Delete. (linux_corefile_thread): Call gcore_elf_build_thread_register_notes. (find_signalled_thread): Delete. (linux_make_corefile_notes): Call gcore_find_signalled_thread.
2021-01-01Update copyright year range in all GDB filesJoel Brobecker1-1/+1
This commits the result of running gdb/copyright.py as per our Start of New Year procedure... gdb/ChangeLog Update copyright year range in copyright header of all GDB files.
2020-12-19Warn about static libs vs. source-highlight only when necessaryBernd Edlinger1-6/+6
Avoid the error message when source-highlight is actually available. 2020-12-19 Bernd Edlinger <bernd.edlinger@hotmail.de> * configure.ac: Move the static libs vs. source-highlight error message to a better place. * configure: Regenerate.
2020-11-15gdb: Make GMP a required dependency for building GDBJoel Brobecker1-0/+3
This commit modifies gdb's configure script to trigger an error if we cannot find a usable libgmp. For the record, making this a requirement was discussed in March 2018: https://sourceware.org/pipermail/gdb-patches/2018-March/147373.html gdb/ChangeLog: * configure.ac: Generate an error if a usable GMP library could not be found. * configure: Regenerate.
2020-11-15gdb/configure: Add --with-libgmp-prefix optionJoel Brobecker1-0/+5
This patch allows a user to tell gdb's configure script where his GMP library is installed. gdb/ChangeLog: * configure.ac: Add support for --with-libgmp-prefix. * Makefile.in (LIBGMP): New variable. (CLIBS): Include $(LIBGMP). * configure, config.in: Regenerate
2020-11-06gdb: better static python detection in configure machineryRomain Geissler1-1/+1
In python 3, itertools is a builtin module, so whether or not the python you link against is a shared or a static one, importing it works. Change the import test to use ctypes which is a dynamic module in both python 2 and 3. gdb/ChangeLog: PR python/26832 * configure: Regenerate. * configure.ac: Check for python modules ctypes instead of itertools.
2020-10-31gdb: modernize configure.acSimon Marchi1-132/+234
Run autoupdate on configure.ac and adjust the indentation of the result for better readability. This removes a bunch of warnings when running `autoreconf -vf -Wall`. The changes are: * Replace AC_INIT with AC_INIT and no arguments plus AC_CONFIG_SRCDIR. * Replace AC_ERROR with AC_MSG_ERROR. * Replace AC_TRY_LINK with AC_LINK_IFELSE. * Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE. * Replace AC_HELP_STRING with AS_HELP_STRING. autoupdate erroneously tries to replace AC_C_LONG_DOUBLE in a comment, which I reverted manually. All the changes in the generated configure file are insignificant whitespaces changes. gdb/ChangeLog: * configure.ac: Modernize. * configure: Re-generate. Change-Id: Ie3a1409c8032a36a6383da964286a46ece9b546e
2020-10-31gdb: use AC_PROG_CC_STDC instead of AM_PROG_CC_STDCSimon Marchi1-1/+0
`autoconf -Wall` notes that AM_PROG_CC_STDC is obsolete: Fixes this autoconf warning: configure.ac:40: warning: 'AM_PROG_CC_STDC': this macro is obsolete. configure.ac:40: You should simply use the 'AC_PROG_CC' macro instead. configure.ac:40: Also, your code should no longer depend upon 'am_cv_prog_cc_stdc', configure.ac:40: but upon 'ac_cv_prog_cc_stdc'. aclocal.m4:770: AM_PROG_CC_STDC is expanded from... configure.ac:40: the top level Since we build with a C++ compiler now, I don't think this is relevant. If you look at the messages removed from gdbsupport/aclocal.m4, it says that this functionality is now integrated in AC_PROG_CC, which we already call. So it might not even make a difference. We had a local version of AM_PROG_CC_STDC, in gdb/acinclude.m4 (only used by gdb/configure.ac), remove it. gdb/ChangeLog: * acinclude.m4 (AM_PROG_CC_STDC): Remove. * configure: Re-generate. * configure.ac: Remove AM_PROG_CC_STDC. gdbsupport/ChangeLog: * aclocal.m4: Re-generate. * configure: Re-generate. * configure.ac: Remove AM_PROG_CC_STDC. Change-Id: Ic824393598805d4f78cda9d119f8af46096e9c73
generated by cgit v1.1 at 2024-12-04 09:29:54 +0000