aboutsummaryrefslogtreecommitdiff
path: root/gdb/configure
AgeCommit message (Collapse)AuthorFilesLines
2025-06-06gdb: unix: allow to use custom baud rateAlexey Lapshin1-0/+2
Modern unix systems allow to set custom baud rate instead of predefined in termios.h. - To use this in Linux it must have BOTHER macro in "asm/termio.h" - MacOS could handle this using IOSSIOSPEED passed to ioctl() Approved-By: Simon Marchi <simon.marchi@efficios.com> Change-Id: I5bc95982f5d90c7030b73f484ecc0f75c060ebf7
2025-06-06gdb/configure: Fix POSIX non-complianceGuinevere Larsen1-23/+16
My recent GDB commit: commit 4b42385c470c5f72f158f382f4d9c36f927aa84f Author: Guinevere Larsen <guinevere@redhat.com> Date: Wed Feb 12 08:25:46 2025 -0300 gdb: Make dwarf support optional at compile time Introduced a change that made the configure script not POSIX compliant, by using fallthrough in some case statements. This commit reworks that part of the change to only use if statements, so that no code is duplicated but things remain POSIX compliant. Reviewed-by: Sam James <sam@gentoo.org> Approved-By: Tom Tromey <tom@tromey.com>
2025-06-03gdb: Make dwarf support optional at compile timeGuinevere Larsen1-10/+55
This commit allows a user to enable or disable dwarf support at compilation time. To do that, a new configure option is introduced, in the form of --enable-gdb-dwarf-support (and the accompanying --disable version). By default, dwarf support is enabled, so no behavior changes occur if a user doesn't use the new feature. If support is disabled, no .c files inside the dwarf2/ subfolder will be compiled into the final binary. To achieve this, this commit also introduces the new macro DWARF_FORMAT_AVAILABLE, which guards the definitions of functions exported from the dwarf reader. If the macro is not defined, there are a couple behaviors that exported functions may have: * no-ops: several functions are used to register things at initialization time, like unwinders. These are turned into no-ops because the user hasn't attempted to read DWARF yet, there's no point in warning that DWARF is unavailable. * warnings: similar to the previous commit, if dwarf would be read or used, the funciton will emit the warning "No dwarf support available." * throw exceptions: If the code that calls a function expects an exceptin in case of errors, and has a try-catch block, an error with the previous message is thrown. I believe that the changed functions should probalby be moved to the dwarf2/public.h header, but that require a much larger refactor, so it is left as a future improvement. Finally, the --enable-gdb-compile configure option has been slightly changed, since compile requires dwarf support. If compile was requested and dwarf was disabled, configure will throw an error. If the option was not used, support will follow what was requested for dwarf (warning the user of what is decided). Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
2025-06-03gdb: wrap mdebug debuginfo reading in ifdefsGuinevere Larsen1-2/+31
This commit aims to allow a user to enable or disable mdebug support at compilation time. To do that, a new configure option is added, called --enable-gdb-mdebug-support (and the accompanying --disable version). By default, support is enabled, and if a user decides to disable support, the file mdebugread.c won't be compiled in the final binary, and the macro MDEBUG_FORMAT_AVAILABLE won't be defined. That macro is used to control the definitions of mdebug reading, either the actual definition in mdebugread.c, or a static inline version that only emits the following warning: > No mdebug support available. Ideally, we'd like to guard the entirity of mdebugread in the macro, but the alpha-mdebug-tdep file uses those directly, and I don't think we should restrict alpha hosts to requiring that debug format compiled in, nor do I understand the tdep file enough to be comfortable disentangling the requirements. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2025-05-30Require Python 3.4Tom Tromey1-2/+2
I believe we previously agreed that the minimum supported Python version should be 3.4. This patch makes this change, harmonizing the documentation (which was inconsistent about the minimum version) and the code. New in v2: rebased, and removed a pre-3.4 workaround from __init__.py. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-by: Kevin Buettner <kevinb@redhat.com> Acked-By: Tom de Vries <tdevries@suse.de> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31870
2025-05-21Minor spelling fixes in gdb directoryTom Tromey1-1/+1
I ran codespell on the gdb directory and fixed a number of minor problems. In a couple cases I replaced a "gdb spelling" (e.g., "readin") with an English one ("reading") where it seemed harmless. I also added "Synopsis" as an accepted spelling. gdb is nowhere near codespell-clean. Approved-By: Tom de Vries <tdevries@suse.de>
2025-04-28Fix 64-bit BFD detection causing build failuresMaciej W. Rozycki1-82/+35
We have a discrepancy with 64-bit BFD handling across our component subdirectories leading to link failures such as: ld: ../opcodes/.libs/libopcodes.a(disassemble.o): in function `disassembler': disassemble.c:(.text+0x65): undefined reference to `print_insn_alpha' ld: disassemble.c:(.text+0x105): undefined reference to `print_insn_ia64' ld: disassemble.c:(.text+0x11d): undefined reference to `print_insn_loongarch' ld: disassemble.c:(.text+0x1a1): undefined reference to `print_insn_big_mips' [...] with some configurations having a 32-bit host and 64-bit BFD, such as: `--host=i386-linux-gnu --target=riscv64-linux-gnu --enable-targets=all'. This is ultimately due to how 64-bit BFD is enabled for bfd/ itself and other subdirectorses and has been a regression from commit 1d5269c994bf ("unify 64-bit bfd checks"). For bfd/ the BFD_64_BIT autoconf macro from config/bfd64.m4 is used combined with this logic in bfd/configure.ac: case ${host64}-${target64}-${want64} in *true*) wordsize=64 bfd64_libs='$(BFD64_LIBS)' all_backends='$(BFD64_BACKENDS) $(BFD32_BACKENDS)' [...] ;; false-false-false) wordsize=32 all_backends='$(BFD32_BACKENDS)' ;; esac where the value of ${wordsize} switches between 32-bit and 64-bit BFD via these pieces: #define BFD_ARCH_SIZE @wordsize@ and: #if BFD_ARCH_SIZE >= 64 #define BFD64 #endif in bfd/bfd-in.h, which ultimately becomes a part of "bfd.h". Then ${host64} is determined in bfd/configure.ac from the host's word size, via the host's pointer size: if test "x${ac_cv_sizeof_void_p}" = "x8"; then host64=true fi And ${target64} is determined in bfd/configure.ac from the target's word size: if test ${target_size} = 64; then target64=true fi Where multiple targets have been requested with `--enable-targets=all' the presence of any 64-bit target will set "true" here. Finally ${want64} is set according to `--enable-64-bit-bfd' user option with an arrangement involving BFD_64_BIT: BFD_64_BIT if test $enable_64_bit_bfd = yes ; then want64=true else want64=false fi which also, redundantly, checks and sets its result upon the host's word size. Lastly ${want64} is also selectively set by target fragments in bfd/config.bfd, which mostly if not completely overlaps with ${target64} setting as described above. Conversely other subdirectories only rely on BFD_64_BIT, so they fail to notice that BFD is 64-bit and do not enable their 64-bit handling where the host requested is 32-bit and 64-bit BFD has been enabled other than with `--enable-64-bit-bfd'. One consequence is opcodes/disassemble.c enables calls to its numerous own 64-bit backends by checking the BFD64 macro from "bfd.h", however does not actually enable said backends in its Makefile. Hence the link errors quoted above. Address the problem then by moving the `--enable-64-bit-bfd' option back to bfd/configure.ac and remove the call to BFD_64_BIT from there and then rewrite the macro in terms of checking for the presence of BFD64 macro in "bfd.h", which is the canonical way of determining whether BFD is 64-bit or not. Rather than running `grep' directly on ../bfd/bfd-in3.h as the opcodes/ fragment used to before the problematic commit: if grep '#define BFD_ARCH_SIZE 64' ../bfd/bfd-in3.h > /dev/null; then run the preprocessor on "bfd.h", which allows to invoke the macro from configure.ac files placed in subdirectories located at deeper levels, by relying on the preprocessor's search path. This requires however that the invokers rely on `all-bfd' rather than `configure-bfd' for their `configure' invocation stage, because "bfd.h" is made by `make all' rather than `configure' in bfd/. Do not cache the result of this check however, as reconfiguring a tree such as to flip `--enable-64-bit-bfd' on or to change a secondary target may affect BFD64 and we have no access to information about secondary targets in BFD_64_BIT. Also remove the ENABLE_BFD_64_BIT automake conditional, as it's not used anywhere. Last but not least remove the hack from gdb/configure.ac to fail builds for `mips*-*-*' hosts where `--enable-targets=all' has been requested, but `--enable-64-bit-bfd' has not as it's no longer needed. Such builds complete successfully now, having enabled 64-bit BFD implicitly. Tested-By: Guinevere Larsen <guinevere@redhat.com> Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Alan Modra <amodra@gmail.com> Approved-By: Luis Machado <luis.machado@arm.com>
2025-04-23gdb: fix bashism in configure.acSam James1-1/+1
Use '=', not '==', as configure has a #!/bin/sh shebang and must work with non-bash shells. Fixes: c4375bc51c861dfa384a01bdb2e460e115710bf9
2025-03-26gdb: add configure option to disable compileGuinevere Larsen1-2/+37
GDB's compile subsystem is deeply tied to GDB's ability to understand DWARF. A future patch will add the option to disable DWARF at configure time, but for that to work, the compile subsystem will need to be entirely disabled as well, so this patch adds that possibility. I also think there is motive for a security conscious user to disable compile for it's own sake. Considering that the code is quite unmaintained, and depends on an equally unmaintained gcc plugin, there is a case to be made that this is an unnecessary increase in the attack surface if a user knows they won't use the subsystem. Additionally, this can make compilation slightly faster and the final binary is around 3Mb smaller. But these are all secondary to the main goal of being able to disable dwarf at configure time. To be able to achieve optional compilation, some of the code that interfaces with compile had to be changed. All parts that directly called compile things have been wrapped by ifdefs checking for compile support. The file compile/compile.c has been setup in a similar way to how python's and guile's main file has been setup, still being compiled but only for with placeholder command. Finally, to avoid several new errors, a new TCL proc was introduced to gdb.exp, allow_compile_tests, which checks if the "compile" command is recognized before the inferior is started and otherwise skips the compile tests. All tests in the gdb.compile subfolder have been updated to use that, and the test gdb.base/filename-completion also uses this. The proc skip_compile_feature_tests to recognize when the subsystem has been disabled at compile time. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
2025-03-17gdbsupport: add some -Wunused-* warning flagsSimon Marchi1-0/+6
Add a few -Wunused-* diagnostic flags that look useful. Some are known to gcc, some to clang, some to both. Fix the fallouts. -Wunused-const-variable=1 is understood by gcc, but not clang. -Wunused-const-variable would be undertsood by both, but for gcc at least it would flag the unused const variables in headers. This doesn't make sense to me, because as soon as one source file includes a header but doesn't use a const variable defined in that header, it's an error. With `=1`, gcc only warns about unused const variable in the main source file. It's not a big deal that clang doesn't understand it though: any instance of that problem will be flagged by any gcc build. Change-Id: Ie20d99524b3054693f1ac5b53115bb46c89a5156 Approved-By: Tom Tromey <tom@tromey.com>
2025-03-17gdbsupport: re-format and sort warning flagsSimon Marchi1-12/+20
Put them one per line and sort alphabetically. Change-Id: Idb6947d444dc6e556a75645b04f97a915bba7a59 Approved-By: Tom Tromey <tom@tromey.com>
2025-03-17gdb-add-index: add --help and --version optionsAndrew Burgess1-0/+3
Update the gdb-add-index script to offer --help and --version options. The script currently accepts the argument '-dwarf-5' with a single leading '-'. As two '--' is more common for long options, the preferred argument form is now '--dwarf-5', the docs have been updated, and the new help text uses this form. For backward compatibility, the old '-dwarf-5' form is still accepted. The new arguments are '--help' or '-h', but I also accept '-help' for consistency with '-dwarf-5'. And likewise for the version argument. Handling of the gdb-add-index script is done basically the same as for gcore and gstack; we use config.status to create a .in file within the build directory, which is then processed by the Makefile to create the final script. The difference with gdb-add-index is that I left the original script as gdb/contrib/gdb-add-index.sh rather than renaming it to something like gdb/contrib/gdb-add-index-1.in, which is how gcore and gstack are handled (though they are not in the contrib directory). The reason for this is that the contrib/cc-with-tweaks.sh script looks for gdb-add-index.sh within the gdb/contrib/ source directory. As the only reason we process gdb-add-index.sh into the build directory is to support the PKGVERSION and VERSION variables, allowing cc-with-tweaks to continue using the unprocessed version seems harmless, and avoids having to change cc-with-tweaks.sh at all. I tested that I can still run tests using the cc-with-gdb-index target board, and that the installed gdb-add-index script correctly shows a version number when asked. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32325 Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
2025-03-13gcore: add -v or --version option to show version numberAndrew Burgess1-3/+2
Based on the work in this commit: commit fb2ded33c1e519659743047ed7817166545b6d91 Date: Fri Dec 20 12:46:11 2024 -0800 Add gstack script This commit adds a '-v' or '--version' option to the existing gcore script. This new option causes the script to print its version number, and then exit. I needed to adjust the getopts handling a little in order to support the long form '--version' argument, but as this makes gcore more consistent with gstack, then this seems like a good thing. The usage message is now getting a little long. Don't worry, I plan to clean that up in the next commit. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32325 Approved-By: Tom Tromey <tom@tromey.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2025-02-05gdb: restrict configure error with all targets and 64 bit bfd to mipsGuinevere Larsen1-3/+10
The recent commit b601c58034ed755fb765fc13782b6876bffd25d4 causes the gdb configure to fail if --enable-targets=all was requested, but 64 bit bfd was not enabled. This was due to a build failure first reported against mips, and that I also encountered building on a 32 bit mips system, but that looked like a general failure. Further examination showed that this is, in fact, mips-specific (or at least, not completely generic) as other targets like debian-i386 and 32-bit arm could build all targets just fine. This commit restricts the new error to only trigger in mips hosts. Approved-By: Andrew Burgess <aburgess@redhat.com>
2025-01-28gdb/configure: fail configure if all targets requested with 32bit bfdGuinevere Larsen1-1/+3
As PR sim/28684 explains, it isn't possible to compile GDB with all targets enabled and not enabling 64 bit bfd. In 64 bit hosts, 64 bit bfd is forced, so the build works, but in 32 bit hosts, that has to be explicitly enabled. I ran into this when I tried compiling GDB on a mips64 machine running a 32 bit OS. Along with the errors in the PR, several other architectures are also required, notably aarch64 and other explicitly 64bit targets. Additionally, some 32 bit files required for the gdb mips target aren't added to the makefile. Considering the last comment in the bug says this isn't going to be fixed on the binutils side, I didn't think it was worth trying to fix the GDB side. Instead, this commit causes the configure script to fail if all targets were requested and 64 bit bfd isn't enabled. If that is ever fixed, we can revert this commit. I considered adding this to the top level configure script, but couldn't figure out how to detect the situation in there, so this was my next best idea. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28684 Approved-by: Kevin Buettner <kevinb@redhat.com>
2024-12-20Add gstack scriptKeith Seitz1-2/+12
This commit adds support for a `gstack' command which Fedora has been carrying for many years. gstack is a natural counterpart to the gcore command. Whereas gcore dumps a core file, gstack prints stack traces of a running process. There are many improvements over Fedora's version of this script. The dependency on procfs is gone; gstack will run anywhere gdb runs. The only runtime dependencies are bash and awk. The script includes suggestions from gdb/32325 to include versioning and help. [If this approach to gdb/32325 is acceptable, I could propagate the solution to gcore/gdb-add-index.] I've rewritten the documentation, integrating it into the User Manual. The manpage is now output using this one source. Example run (on x86_64 Fedora 40) $ gstack --help Usage: gstack [-h|--help] [-v|--version] PID Print a stack trace of a running program -h, --help Print this message then exit. -v, --version Print version information then exit. $ gstack -v GNU gstack (GDB) 16.0.50.20241119-git $ gstack 12345678 Process 12345678 not found. $ gstack $(pidof emacs) Thread 6 (Thread 0x7fd5ec1c06c0 (LWP 2491423) "pool-spawner"): #0 0x00007fd6015ca3dd in syscall () at /lib64/libc.so.6 #1 0x00007fd60b31eccd in g_cond_wait () at /lib64/libglib-2.0.so.0 #2 0x00007fd60b28a61b in g_async_queue_pop_intern_unlocked () at /lib64/libglib-2.0.so.0 #3 0x00007fd60b2f1a03 in g_thread_pool_spawn_thread () at /lib64/libglib-2.0.so.0 #4 0x00007fd60b2f0813 in g_thread_proxy () at /lib64/libglib-2.0.so.0 #5 0x00007fd6015486d7 in start_thread () at /lib64/libc.so.6 #6 0x00007fd6015cc60c in clone3 () at /lib64/libc.so.6 #7 0x0000000000000000 in ??? () Thread 5 (Thread 0x7fd5eb9bf6c0 (LWP 2491424) "gmain"): #0 0x00007fd6015be87d in poll () at /lib64/libc.so.6 #1 0x0000000000000001 in ??? () #2 0xffffffff00000001 in ??? () #3 0x0000000000000001 in ??? () #4 0x000000002104cfd0 in ??? () #5 0x00007fd5eb9be320 in ??? () #6 0x00007fd60b321c34 in g_main_context_iterate_unlocked.isra () at /lib64/libglib-2.0.so.0 Thread 4 (Thread 0x7fd5eb1be6c0 (LWP 2491425) "gdbus"): #0 0x00007fd6015be87d in poll () at /lib64/libc.so.6 #1 0x0000000020f9b558 in ??? () #2 0xffffffff00000003 in ??? () #3 0x0000000000000003 in ??? () #4 0x00007fd5d8000b90 in ??? () #5 0x00007fd5eb1bd320 in ??? () #6 0x00007fd60b321c34 in g_main_context_iterate_unlocked.isra () at /lib64/libglib-2.0.so.0 Thread 3 (Thread 0x7fd5ea9bd6c0 (LWP 2491426) "emacs"): #0 0x00007fd6015ca3dd in syscall () at /lib64/libc.so.6 #1 0x00007fd60b31eccd in g_cond_wait () at /lib64/libglib-2.0.so.0 #2 0x00007fd60b28a61b in g_async_queue_pop_intern_unlocked () at /lib64/libglib-2.0.so.0 #3 0x00007fd60b28a67c in g_async_queue_pop () at /lib64/libglib-2.0.so.0 #4 0x00007fd603f4d0d9 in fc_thread_func () at /lib64/libpangoft2-1.0.so.0 #5 0x00007fd60b2f0813 in g_thread_proxy () at /lib64/libglib-2.0.so.0 #6 0x00007fd6015486d7 in start_thread () at /lib64/libc.so.6 #7 0x00007fd6015cc60c in clone3 () at /lib64/libc.so.6 #8 0x0000000000000000 in ??? () Thread 2 (Thread 0x7fd5e9e6d6c0 (LWP 2491427) "dconf worker"): #0 0x00007fd6015be87d in poll () at /lib64/libc.so.6 #1 0x0000000000000001 in ??? () #2 0xffffffff00000001 in ??? () #3 0x0000000000000001 in ??? () #4 0x00007fd5cc000b90 in ??? () #5 0x00007fd5e9e6c320 in ??? () #6 0x00007fd60b321c34 in g_main_context_iterate_unlocked.isra () at /lib64/libglib-2.0.so.0 Thread 1 (Thread 0x7fd5fcc45280 (LWP 2491417) "emacs"): #0 0x00007fd6015c9197 in pselect () at /lib64/libc.so.6 #1 0x0000000000000000 in ??? () Since this is essentially a complete rewrite of the original script and documentation, I've chosen to only keep a 2024 copyright date. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
2024-12-04[gdb/build] Fix build breaker on mingw-w64Simon Marchi1-1/+0
The mingw-w64 build breaks currently: ... In file included from gdb/cli/cli-cmds.c:58: gdbsupport/eintr.h: In function ‘pid_t gdb::waitpid(pid_t, int*, int)’: gdbsupport/eintr.h:77:35: error: ‘::waitpid’ has not been declared; \ did you mean ‘gdb::waitpid’? 77 | return gdb::handle_eintr (-1, ::waitpid, pid, wstatus, options); | ^~~~~~~ | gdb::waitpid gdbsupport/eintr.h:75:1: note: ‘gdb::waitpid’ declared here 75 | waitpid (pid_t pid, int *wstatus, int options) | ^~~~~~~ ... This is a regression since commit 658a03e9e85 ("[gdbsupport] Add gdb::{waitpid,read,write,close}"), which moved the use of ::waitpid from run_under_shell, where it was used conditionally: ... #if defined(CANT_FORK) || \ (!defined(HAVE_WORKING_VFORK) && !defined(HAVE_WORKING_FORK)) ... #else ... int ret = gdb::handle_eintr (-1, ::waitpid, pid, &status, 0); ... to gdb::waitpid, where it's used unconditionally: ... inline pid_t waitpid (pid_t pid, int *wstatus, int options) { return gdb::handle_eintr (-1, ::waitpid, pid, wstatus, options); } ... Likewise for ::wait. Guard these uses with HAVE_WAITPID and HAVE_WAIT. Reproduced and tested by doing a mingw-w64 cross-build on x86_64-linux. Reported-By: Simon Marchi <simark@simark.ca> Co-Authored-By: Tom de Vries <tdevries@suse.de>
2024-12-02gdb/configure.ac: remove elf_hp.h checkSimon Marchi1-2/+0
The comment says this is for HP/UX, which is no longer supported. There should be no functional changes with this, since nothing checks HAVE_ELF_HP_H. Change-Id: Ie897fc64638c9fea28463e1bf69e450c3673fd84
2024-12-02gdb, gdbserver, gdbsupport: flatten and sort some list in configure filesSimon Marchi1-18/+88
This makes the lists easier sort read and modify. There are no changes in the generated config.h files, so I'm confident this brings no functional changes. Change-Id: Ib6b7fc532bcd662af7dbb230070fb1f4fc75f86b
2024-11-23[gdb/contrib] Add two rules in common-misspellings.txtTom de Vries1-1/+1
Eli mentioned [1] that given that we use US English spelling in our documentation, we should use "behavior" instead of "behaviour". In wikipedia-common-misspellings.txt there's a rule: ... behavour->behavior, behaviour ... which leaves this as a choice. Add an overriding rule to hardcode the choice to common-misspellings.txt: ... behavour->behavior ... and add a rule to rewrite behaviour into behavior: ... behaviour->behavior ... and re-run spellcheck.sh on gdb*. Tested on x86_64-linux. [1] https://sourceware.org/pipermail/gdb-patches/2024-November/213371.html
2024-10-08gdb: include --enable-targets in 'show configuration' outputAndrew Burgess1-1/+9
Include the value of configuration flag --enable-targets in the output of GDB command 'show configuration' and also in the output printed for 'gdb --configuration'. This will make it easier to see how GDB was built. No tests added or updated as we can't really check for a specific flag appearing or not appearing on the configuration output. But we do print the configuration within lib/gdb.exp to check which features are built into GDB, so if this change broke configuration printing then plenty of tests should stop working (they don't). Approved-By: Tom Tromey <tom@tromey.com>
2024-08-14btrace, python: Enable ptwrite filter registration.Felix Willgerodt1-0/+11
By default GDB will be printing the hex payload of the ptwrite package as auxiliary information. To customize this, the user can register a ptwrite filter function in python, that takes the payload and the PC as arguments and returns a string which will be printed instead. Registering the filter function is done using a factory pattern to make per-thread filtering easier. Approved-By: Markus Metzger <markus.t.metzger@intel.com>
2024-08-12gdb/amd-dbgapi-target: adjust to amd-dbgapi 0.75.0Simon Marchi1-10/+10
amd-dbgapi 0.75 (from ROCm release 6.2.0) brings a few backwards incompatible changes. Adjust the amd-dbgapi target code accordingly. Given that the AMD GPU port in upstream GDB today is of limited use (it's still missing important pieces), we don't really care about supporting amd-dbgapi versions other than the latest stable one, so no effort is made to keep compatibility with versions 6.1.2 and older. The changes are: - AMD_DBGAPI_EXCEPTION_WAVE_APERTURE_VIOLATION was renamed to AMD_DBGAPI_EXCEPTION_WAVE_ADDRESS_ERROR (the old name still exists but is deprecated), use the latter. - In the callbacks structure, the get_os_pid callback was replaced with client_process_get_info, which is more general and extensible. Convert our get_os_pid to a new, equivalent, client_process_get_info callback. Handle the new AMD_DBGAPI_CLIENT_PROCESS_INFO_CORE_STATE query, but just return "not available". - The xfer_global_memory callback was added to the callbacks structure, add that new callback. - Update configure.ac to check for amd-dbgapi >= 0.75.0. Change-Id: If012398cf55ebf6146b007f6b4e8395dd48ef981 Approved-By: Lancelot Six <lancelot.six@amd.com> Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
2024-08-02gdb, gdbserver, gdbsupport: remove -Wno-vla-cxx-extensionSimon Marchi1-1/+1
Now that all known uses of VLAs within GDB are removed, remove the `-Wno-vla-cxx-extension` (which was used to silence clang warnings) and add `-Wvla`, such that any use of a VLA will trigger a warning. Change-Id: I69a8d7f93f973743165b0ba46f9c2ea8adb89025 Reviewed-By: Keith Seitz <keiths@redhat.com>
2024-06-20Revert "Remove LIBINTL_DEP"Alan Modra1-2/+4
This reverts commit e874cbd3879843a83e4bcc4b54cd7107387b1df6. The patch was wrong. LIBINTL_DEP is needed with an in-tree gettext.
2024-06-20Remove LIBINTL_DEPAlan Modra1-4/+2
The intl directory in the source no longer exists. LIBINTL_DEP is thus always empty. Remove references to it. config/ * gettext-sister.m4: Don't AC_SUBST LIBINTL_DEP. bfd/ * Makefile.in: Regenerate. * configure: Regenerate. binutils/ * Makefile.am (*_DEPENDENCIES): Remove LIBINTL_DEP. * Makefile.in: Regenerate. * configure: Regenerate. gas/ * Makefile.am (as_new_DEPENDENCIES): Remove LIBINTL_DEP. * Makefile.in: Regenerate. * configure: Regenerate. gdb/ * Makefile.in (INTL_DEPS): Don't set or reference. * configure: Regenerate. gdbserver/ * Makefile.in (INTL_DEPS): Don't set or reference. gdbsupport/ * Makefile.in: Regenerate. * configure: Regenerate. gold/ * Makefile.am (deps_var): Remove LIBINTL_DEP. (incremental_dump_DEPENDENCIES, dwp_DEPENDENCIES): Likewise. * Makefile.in: Regenerate. * configure: Regenerate. * testsuite/Makefile.am (DEPENDENCIES): Remove LIBINTL_DEP. * testsuite/Makefile.in: Regenerate. gprof/ * Makefile.am (gprof_DEPENDENCIES): Remove LIBINTL_DEP. * Makefile.in: Regenerate. * configure: Regenerate. ld/ * Makefile.am (ld_new_DEPENDENCIES): Remove LIBINTL_DEP. * Makefile.in: Regenerate. * configure: Regenerate. libctf/ * Makefile.in: Regenerate. * configure: Regenerate. opcodes/ * configure.ac (BUILD_LIBS): Remove LIBINTL. (BUILD_LIB_DEPS): Remove LIBINTL_DEP. * Makefile.in: Regenerate. * configure: Regenerate.
2024-06-08Fix typo in warning in gdb/configureTom Tromey1-2/+2
Eli pointed out that "babeltrace" is misspelled in a warning in gdb/configure. This patch fixes the typo.
2024-05-16Stop 'configure --enable-threading' if std::thread doesn't workPedro Alves1-3/+11
Currently, if you configure gdb with explicit --enable-threading, but then configure detects std::thread does not work, configure silently disables threading support and continues configuring. This patch makes that scenario cause a configuration error, like so: $ /home/pedro/gdb/src/configure --enable-threading && make ... configure: error: std::thread does not work; disable threading make[1]: *** [Makefile:11225: configure-gdbsupport] Error 1 make[1]: Leaving directory '/home/pedro/gdb/build-windows-threads' make: *** [Makefile:1041: all] Error 2 $ Additionally, if you don't explicitly pass --enable-threading, and std::thread does not work, we will now get a warning (and the build continues): $ /home/pedro/gdb/src/configure && make ... configure: WARNING: std::thread does not work; disabling threading ... This is similar to how we handle --enable-tui and missing curses. The code and error/warning messages were borrowed from there. Change-Id: I73a8b580d1e2a796b23136920c0e181408ae1b22 Approved-By: Tom Tromey <tom@tromey.com>
2024-05-06Fix build issues with mingw toolchainBernd Edlinger1-0/+1
With a x86_64-pc-mingw32 toolchain there is a build issue whether or not the --disable-threading option is used. The problem happens because _WIN32_WINNT is defined to 0x501 before #include <mutex> which makes the compilation abort due to missing support for __gthread_cond_t in std_mutex.h, which is conditional on _WIN32_WINNT >= 0x600. Fix the case when --disable-threading is used, by only including <mutex> in gdb/complaints.c when STD_CXX_THREAD is defined. Additionally make the configure script try to #include <mutex> to automatically select --disable-threading when the header file is not able to compile. Approved-By: Tom Tromey <tom@tromey.com>
2024-04-17gdbsupport, gdbserver, gdb: use -Wno-vla-cxx-extensionSimon Marchi1-0/+1
When building with clang 18, I see: CXX aarch64-linux-tdep.o /home/smarchi/src/binutils-gdb/gdb/aarch64-linux-tdep.c:1299:26: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension] 1299 | gdb_byte za_zeroed[za_bytes]; | ^~~~~~~~ /home/smarchi/src/binutils-gdb/gdb/aarch64-linux-tdep.c:1299:26: note: read of non-const variable 'za_bytes' is not allowed in a constant expression /home/smarchi/src/binutils-gdb/gdb/aarch64-linux-tdep.c:1282:10: note: declared here 1282 | size_t za_bytes = std::pow (sve_vl_from_vg (svg), 2); | ^ Since we are using VLAs right now, that warning doesn't make sense for us. add `-Wno-vla-cxx-extension` to the list of warning flags we try to enable. If we ever choose to disallow VLAs, we can remove that flag. Change-Id: Ie41feafc50c343f6e75333d4f836ce32fbeb6d8c
2024-04-08gdb/configure: realign the AC_ARG_ENABLE(sim, ....) blockAndrew Burgess1-6/+6
Following the suggestion in this review comment: https://inbox.sourceware.org/gdb-patches/9420bbb0-2614-4847-9157-8562f8a62d03@simark.ca this commit realigns the AC_ARG_ENABLE(sim, ....) block. I've added additional [...] quoting in a couple of places, which is inline with how other AC_ARG_ENABLE blocks are formatted within GDB's configure.ac file. There should be no change in how GDB configures or builds after this commit.
2024-04-08gdb/configure: use AC_MSG_NOTICE not a direct echo callAndrew Burgess1-2/+4
After the recent commits, I noticed that GDB's configure script would still emit two lines even when run in silent mode. If you touch gdb/Makefile.in and then run 'make all' in the gdb/ build directory you'll see this: GEN config.status enable_sim = no enableval = no Obviously the 'no' might be 'yes' depending on how you actually configured GDB. This is caused by two direct invocations of 'echo' in GDB's configure.ac script. In this commit I replace these calls with use of AC_MSG_NOTICE instead. Now when configure is run with the --silent command line option these lines will not be printed. There should be no changes in the built GDB after this commit. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-01-10gdbsupport: tighten up libiberty code a bit with dnlMike Frysinger1-3/+1
No functional change here, just touch up generated output slightly. Approved-By: Tom Tromey <tom@tromey.com>
2024-01-10gdb: libiberty: switch to AC_CHECK_DECLS_ONCEMike Frysinger1-58/+69
Only check these decls once in case other m4 macros also look for them. Approved-By: Tom Tromey <tom@tromey.com>
2023-11-30[gdb/build] Fix adding -DNDEBUG to python flags of release buildTom de Vries1-3562/+3563
In gdb/configure the line: ... $development || tentative_python_cflags="$tentative_python_cflags -DNDEBUG" ... intends to ensure that -DNDEBUG is added to the python flags of a release build. However, when building gdb-14-branch we have: ... configure:22024: checking compiler flags for python code ... configure:22047: result: -fno-strict-aliasing -fwrapv ... This is a regression since commit db6878ac553 ("Move sourcing of development.sh to GDB_AC_COMMON"), which introduced a reference before assignment: ... $development || tentative_python_cflags="$tentative_python_cflags -DNDEBUG" ... . $srcdir/../bfd/development.sh ... and consequently -DNDEBUG is never added. [ This was not obvious to me, but apparently evaluating an empty or undefined variable in this context is similar to using ':' or 'true', so the line is evaluated as: ... true || tentative_python_cflags="$tentative_python_cflags -DNDEBUG" ... ] Fix this by moving GDB_AC_COMMON up in gdb/configure.ac, similar to how that was done for gdbserver/configure.ac in commit db6878ac553. [ Unfortunately, the move might introduce issues similar to the one we're fixing, and I'm not sure how to check for this. Shellcheck doesn't detect this type of problem. FWIW, I did run shellcheck (using arguments -xa, in the src/gdb directory to make sure ../bfd/development.sh is taken into account) before and after and observed that the number of lines/words/chars in the shellcheck output is identical. ] Build & tested on top of trunk. Also build on top of gdb-14-branch, and observed this in gdb/config.log: ... configure:25214: checking compiler flags for python code ... configure:25237: result: -fno-strict-aliasing -fwrapv -DNDEBUG ... Approved-By: Tom Tromey <tom@tromey.com> PR build/31099 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31099
2023-11-29Switch to -Wimplicit-fallthrough=5Tom Tromey1-1/+1
This changes the various gdb-related directories to use -Wimplicit-fallthrough=5, meaning that only the fallthrough attribute can be used in switches -- special 'fallthrough' comments will no longer be usable. Approved-By: Pedro Alves <pedro@palves.net>
2023-11-15Finalized intl-update patchesArsen Arsenovi?1-752/+2404
* intl: Remove directory. Replaced with out-of-tree GNU gettext. * .gitignore: Add '/gettext*'. * configure.ac (host_libs): Replace intl with gettext. (hbaseargs, bbaseargs, baseargs): Split baseargs into {h,b}baseargs. (skip_barg): New flag. Skips appending current flag to bbaseargs. <library exemptions>: Exempt --with-libintl-{type,prefix} from target and build machine argument passing. * configure: Regenerate. * Makefile.def (host_modules): Replace intl module with gettext module. (configure-ld): Depend on configure-gettext. * Makefile.in: Regenerate. * src-release.sh: Remove references to the intl/ directory.
2023-10-28gdb/gdbsupport/gdbserver: Require c++17Lancelot Six1-25/+1519
This patch proposes to require a C++17 compiler to build gdb / gdbsupport / gdbserver. Before this patch, GDB required a C++11 compiler. The general policy regarding bumping C++ language requirement in GDB (as stated in [1]) is: Our general policy is to wait until the oldest compiler that supports C++NN is at least 3 years old. Rationale: We want to ensure reasonably widespread compiler availability, to lower barrier of entry to GDB contributions, and to make it easy for users to easily build new GDB on currently supported stable distributions themselves. 3 years should be sufficient for latest stable releases of distributions to include a compiler for the standard, and/or for new compilers to appear as easily installable optional packages. Requiring everyone to build a compiler first before building GDB, which would happen if we required a too-new compiler, would cause too much inconvenience. See the policy proposal and discussion [here](https://sourceware.org/ml/gdb-patches/2016-10/msg00616.html). The first GCC release which with full C++17 support is GCC-9[2], released in 2019[3], which is over 4 years ago. Clang has had C++17 support since Clang-5[4] released in 2018[5]. A discussions with many distros showed that a C++17-able compiler is always available, meaning that this no hard requirement preventing us to require it going forward. [1] https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#When_is_GDB_going_to_start_requiring_C.2B-.2B-NN_.3F [2] https://gcc.gnu.org/projects/cxx-status.html#cxx17 [3] https://gcc.gnu.org/gcc-9/ [4] https://clang.llvm.org/cxx_status.html [5] https://releases.llvm.org/ Change-Id: Id596f5db17ea346e8a978668825787b3a9a443fd Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>
2023-10-28gdb/ax_cxx_compile_stdcxx.m4: upgradeLancelot Six1-10/+34
This patch upgrades gdb/ax_cxx_compile_stdcxx.m4 to follow changes available in [1] and regenerates the configure script. [1] https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx.html Change-Id: I5b16adc65c9e48a13ad65202d58ab7a9d487214e Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>
2023-10-12Move -lsocket check to common.m4Tom Tromey1-60/+59
A user pointed out that the -lsocket check in gdb should also apply to gdbserver -- otherwise it can't find the Solaris socketpair. This patch makes the change. It also removes a couple of redundant function checks from gdb's configure.ac. This was tested by the person who reported the bug. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30927 Approved-By: Pedro Alves <pedro@palves.net>
2023-10-05gdb/configure.ac: Add option --with-additional-debug-dirsThiago Jung Bauermann1-2/+17
If you want to install GDB in a custom prefix, have it look for debug info in that prefix but also in the distro's default location (typically, /usr/lib/debug) and run the GDB testsuite before doing "make install", you have a bit of a problem: Configuring GDB with '--prefix=$PREFIX' sets the GDB 'debug-file-directory' parameter to $PREFIX/lib/debug. Unfortunately this precludes GDB from looking for distro-installed debug info in /usr/lib/debug. For regular GDB use you could set debug-file-directory to $PREFIX:/usr/lib/debug in $PREFIX/etc/gdbinit so that GDB will look in both places, but if you want to run the testsuite then that doesn't help because in that case GDB runs with the '-nx' option. There's the configure option '--with-separate-debug-dir' to set the default value for 'debug-file-directory', but it accepts only one directory and not a list. I considered modifying it to accept a list, but it's not obvious how to do that because its value is also used by BFD, as well as processed for "relocatability". I thought it was simpler to add a new option to specify a list of additional directories that will be appended to the debug-file-directory setting. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
2023-09-27config/debuginfod.m4: Add check for libdebuginfod 0.188Aaron Merey1-1/+107
Add check for libdebuginfod 0.188 in AC_DEBUGINFOD and if found define macro HAVE_LIBDEBUGINFOD_FIND_SECTION. This macro indicates support for downloading ELF sections from debuginfod servers.
2023-08-12regen configAlan Modra1-30/+86
This regenerates config files changed by the previous 44 commits. Note that subject lines in these commits mostly match the gcc git originating commit.
2023-07-12[gdb/tui] Assume HAVE_WBORDERTom de Vries1-1/+1
The tui border-kind setting allows values acs, ascii and space. The values ascii and space however don't work well with !HAVE_WBORDER. Fix this by removing the !HAVE_WBORDER case, which was introduced for Ultrix support, which is now obsolete. Tested on x86_64-linux. PR tui/30580 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30580 Approved-By: Tom Tromey <tom@tromey.com>
2023-03-07gdb: Fix GDB_AC_CHECK_BFD macro regressionRichard Purdie1-2/+2
Commit 5218fa9e8937b007d554f1e01c2e4ecdb9b7e271, "gdb: use libtool in GDB_AC_CHECK_BFD" dropped passing in existing LDFLAGS. In our environment, this caused the configure check "checking for ELF support in BFD" to stop working causing build failures as we need our LDFLAGS to be used for correct linking. That change also meant the code failed to match the comments. Add back the missing LDFLAGS preservation, fix our builds and match the comment. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Change-Id: Ie91509116fab29f95b9db1ff0b6ddc280d460112 Approved-By: Simon Marchi <simon.marchi@efficios.com> Reviewed-By: Jose E. Marchesi <jose.marchesi@oracle.com>
2023-02-23gdb: remove --disable-gdbmi configure optionSimon Marchi1-29/+2
I noticed that the --disable-gdbmi option was broken for almost a year (since 740b42ceb7c "gdb/python/mi: create MI commands using python"). The problem today is the python/py-cmd.c file. It is included in the build if Python support is enabled, and it calls into some MI functions (e.g. insert_mi_cmd_entry). If MI support is disabled, we get some undefined symbols like: mold: error: undefined symbol: insert_mi_cmd_entry(std::unique_ptr<mi_command, std::default_delete<mi_command> >) >>> referenced by py-micmd.c >>> python/py-micmd.o:(micmdpy_install_command(micmdpy_object*)) The python/py-cmd.c file should be included in the build if both Python and MI support are enabled. It is not a case we support today, but it could be done with a bit more configure code. However, I think we should just remove the --disable-gdbmi option, and just include MI support unconditionally. Tom Tromey proposed a while ago to remove this option, but it ended staying: https://inbox.sourceware.org/gdb-patches/20180628172132.28843-1-tom@tromey.com/ However, there was no strong opposition to remove it. The argument was just "bah, it doesn't hurt anybody". But given today's case, I would rather remove complexity rather than add some. I couldn't find anybody caring deeply for that option, and it's not like MI adds any external dependency. It's just a bit more code. Removing the option will not break anybody using --disable-gdbmi (it can be found in many build scripts [1]), since we don't flag invalid configure flags. So, remove the option from configure.ac, and adjust Makefile.in accordingly to always include the MI objects in the build. [1] https://github.com/search?q=%22--disable-gdbmi%22&type=code Change-Id: Ifcaa8c9fc4abc6fa686ed5fd984598644f745240 Approved-By: Tom Tromey <tom@tromey.com>
2023-02-21gdb: add --with-curses to --configuration outputPhilippe Blain1-4/+4
'gdb --configuration' does not mention if GDB was built with curses. Since b5075fb68d4 (Rename to allow_tui_tests, 2023-01-08) it does show --enable-tui (or --disable-tui), but one might want to know if GDB was built with curses independently of the availability of the TUI. Since configure.ac uses AC_SEARCH_LIBS to check for the curses library, we do not get an automatically defined HAVE_LIBCURSES symbol in config.in. We do have symbols defined by AC_CHECK_HEADERS (HAVE_CURSES_H, etc.) but it would be cumbersome to use those in print_gdb_configuration because we would have to check for all 6 symbols corresponding the 6 headers listed. This would also increase the maintenance burden if support for other variations of curses are added. Instead, define 'HAVE_LIBCURSES' ourselves by adding an 'action-if-found' argument to AC_SEARCH_LIBS, and use it in print_gdb_configuration. While at it, remove the condition on 'ac_cv_search_waddstr' and set 'curses_found' directly in 'action-if-found'. Change-Id: Id90e3d73990e169cee51bcc3e1d52072cfacd5b8 Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-14gdb: remove unnecessary tui directory check in configureSimon Marchi1-11/+9
I suppose this was possible in the CVS days for the tui directory to be missing, but it's not really possible nowaday. Well, a user could delete the directory from their source tree but... it doesn't make sense. Remove the check for that directory in configure. Change-Id: Iea1412f5e5482ed003015030132ec22150c7d0b3 Approved-By: Tom Tromey <tom@tromey.com>
2023-02-13Fix doc build dependencies for --with-system-readlineKeith Seitz1-2/+6
PR build/30108 concerns building gdb documentation with --with-sytem-readline. If the in-tree readline directory is missing, though, the docs will fail to build: make[4]: Entering directory '/home/keiths/work/readline-doc-issue/linux/gdb/doc' make[4]: *** No rule to make target '../../../src/gdb/doc/../../readline/readline/doc/rluser.texi', needed by 'gdb.info'. Stop. The listed file (and hsuser.texi) are conditionally included by gdb.texinfo. When system readline is used, gdb/configure.ac will leave READLINE_TEXI_INCFLAGS empty, causing doc/Makefile.in to output a line to $BUILD/doc/GDBvn.texi with "@set SYSTEM_READLINE". This surpresses the inclusion of the missing files. They are not needed or used in this scenario. However, GDB_DOC_SOURCE_INCLUDES always lists these two files as dependencies, thus provoking the build error whenever readline/ is missing. This patch fixes this by creating (essentially) a conditional setting of the dependencies to be included from readline.
2023-02-13gdb: 'show config' shows --with[out]-amd-dbgapiLancelot SIX1-0/+3
Ensure that the "show configuration" command and the "--configuration" command line switch shows if GDB was built with the AMDGPU support or not. This will be used in a later patch in this series. Approved-By: Simon Marchi <simon.marchi@efficios.com>
generated by cgit v1.1 at 2025-07-12 11:35:50 +0000