aboutsummaryrefslogtreecommitdiff
path: root/gdb/config.in
AgeCommit message (Collapse)AuthorFilesLines
2023-11-15Finalized intl-update patchesArsen Arsenovi?1-1/+16
* 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-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-05gdb/configure.ac: Add option --with-additional-debug-dirsThiago Jung Bauermann1-0/+3
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-0/+3
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-07-12[gdb/tui] Assume HAVE_WBORDERTom de Vries1-3/+0
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-21gdb: add --with-curses to --configuration outputPhilippe Blain1-0/+3
'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-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>
2022-12-21Use toplevel configure for GMP and MPFR for gdbAndrew Pinski1-6/+0
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-07gdb: link executables with libtoolJose E. Marchesi1-0/+4
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-0/+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-04-15Remove WITH_SIM defineTom Tromey1-3/+0
Since score-tdep.c was removed, the WITH_SIM define is not used in gdb. This patch removes it. Note that re-running autoheader shows a separate change that was missed. I've kept it in this patch to avoid extra work.
2022-03-21gdb: re-generate config.inSimon Marchi1-3/+0
I'm getting this diff when running `autoreconf -vf`. Change-Id: Id5f009d0f0481935c1ee9df5332cb4bf45fbd32d
2022-01-01unify 64-bit bfd checksMike Frysinger1-3/+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.
2021-11-23configure.ac: Check for the readline.h explicitlyAlexandra Hájková1-0/+3
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-09Fix build on rhES5Tom Tromey1-0/+4
The rhES5 build failed due to an upstream import a while back. The bug here is that, while the 'personality' function exists, ADDR_NO_RANDOMIZE is only defined in <linux/personality.h>, not <sys/personality.h>. However, <linux/personality.h> does not declare the 'personality' function, and <sys/personality.h> and <linux/personality.h> cannot both be included. This patch restores one of the removed configure checks and updates the code to check it. We had this as a local patch at AdaCore, because it seemed like there was no interest upstream. However, now it turns out that this fixes PR build/28555, so I'm sending it now.
2021-09-28gdb: use libbacktrace to create a better backtrace for fatal signalsAndrew Burgess1-0/+3
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/+6
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-05gdbsupport/common.m4: check for sigtimedwaitSimon Marchi1-0/+3
The next patch will make the use of sigtimedwait conditional to whether the platform provides it. Start by adding a configure check for it. gdbsupport/ChangeLog: * common.m4 (GDB_AC_COMMON): Check for sigtimedwait. * config.in, configure: Re-generate. gdb/ChangeLog: * config.in, configure: Re-generate. gdbserver/ChangeLog: * config.in, configure: Re-generate. Change-Id: Ic7613fe14521b966b4d991bbcd0933ab14629c05
2021-06-14fbsd nat: Disable address space randomization when requested.John Baldwin1-0/+3
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-05-08Don't run personality syscall at configure time; don't check it at allPedro Alves1-7/+0
Currently, in order to tell whether support for disabling address space randomization on Linux is available, GDB checks if the personality syscall works, at configure time. I.e., it does a run test, instead of a compile/link test: AC_RUN_IFELSE([PERSONALITY_TEST], [have_personality=true], [have_personality=false], This is a bit bogus, because the machine the build is done on may not (and is when you consider distro gdbs) be the machine that eventually runs gdb. It would be better if this were a compile/link test instead, and then at runtime, GDB coped with the personality syscall failing. Actually, GDB already copes. One environment where this is problematic is building GDB in a Docker container -- by default, Docker runs the container with seccomp, with a profile that disables the personality syscall. You can tell Docker to use a less restricted seccomp profile, but I think we should just fix it in GDB. "man 2 personality" says: This system call first appeared in Linux 1.1.20 (and thus first in a stable kernel release with Linux 1.2.0); library support was added in glibc 2.3. ... ADDR_NO_RANDOMIZE (since Linux 2.6.12) With this flag set, disable address-space-layout randomization. glibc 2.3 was released in 2002. Linux 2.6.12 was released in 2005. The original patch that added the configure checks was submitted in 2008. The first version of the patch that was submitted to the list called personality from common code: https://sourceware.org/pipermail/gdb-patches/2008-June/058204.html and then was moved to Linux-specific code: https://sourceware.org/pipermail/gdb-patches/2008-June/058209.html Since HAVE_PERSONALITY is only checked in Linux code, and ADDR_NO_RANDOMIZE exists for over 15 years, I propose just completely removing the configure checks. If for some odd reason, some remotely modern system still needs a configure check, then we can revert this commit but drop the AC_RUN_IFELSE in favor of always doing the AC_LINK_IFELSE cross-compile fallback. gdb/ChangeLog: * linux-nat.c (linux_nat_target::supports_disable_randomization): Remove references to HAVE_PERSONALITY. * nat/linux-personality.c: Remove references to HAVE_PERSONALITY. (maybe_disable_address_space_randomization) (~maybe_disable_address_space_randomizatio): Remove references to HAVE_PERSONALITY. * config.in, configure: Regenerate. gdbserver/ChangeLog: * linux-low.cc: (linux_process_target::supports_disable_randomization): Remove reference to HAVE_PERSONALITY. * config.in, configure: Regenerate. gdbsupport/ChangeLog: * common.m4 (personality test): Remove.
2021-04-21[gdb/build] Hardcode --with-included-regexTom de Vries1-3/+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'.
2020-11-15gdb/configure: Add --with-libgmp-prefix optionJoel Brobecker1-0/+3
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-09-16Require kinfo_get_file and kinfo_get_vmmap for FreeBSD hosts.John Baldwin1-4/+1
FreeBSD systems have provided these functions in libutil since 7.1 release. The most recent release without support is 6.4 released in November of 2008. This also requires libutil-freebsd on GNU/kFreeBSD systems. I assume that those systems have supported kinfo_get_file and kinfo_get_vmmap over a similar timeframe. gdb/ChangeLog: * configure.ac: Remove check for kinfo_getvmmap(). * configure, config.in: Regenerate. * fbsd-nat.c (fbsd_read_mapping): Remove (fbsd_nat_target::find_memory_regions): Remove the procfs version. (fbsd_nat_target::info_proc): Assume kinfo_getfile() and kinfo_get_vmmap() are always present. gdbsupport/ChangeLog: * common.m4 (GDB_AC_COMMON): Refactor checks for kinfo_getfile(). * configure, config.in: Regenerate.
2020-07-30Unify Solaris procfs and largefile handlingRainer Orth1-0/+3
GDB currently doesn't build on 32-bit Solaris: * On Solaris 11.4/x86: In file included from /usr/include/sys/procfs.h:26, from /vol/src/gnu/gdb/hg/master/dist/gdb/i386-sol2-nat.c:24: /usr/include/sys/old_procfs.h:31:2: error: #error "Cannot use procfs in the large file compilation environment" #error "Cannot use procfs in the large file compilation environment" ^~~~~ * On Solaris 11.3/x86 there are several more instances of this. The interaction between procfs and large-file support historically has been a royal mess on Solaris: * There are two versions of the procfs interface: ** The old ioctl-based /proc, deprecated and not used any longer in either gdb or binutils. ** The `new' (introduced in Solaris 2.6, 1997) structured /proc. * There are two headers one can possibly include: ** <procfs.h> which only provides the structured /proc, definining _STRUCTURED_PROC=1 and then including ... ** <sys/procfs.h> which defaults to _STRUCTURED_PROC=0, the ioctl-based /proc, but provides structured /proc if _STRUCTURED_PROC == 1. * procfs and the large-file environment didn't go well together: ** Until Solaris 11.3, <sys/procfs.h> would always #error in 32-bit compilations when the large-file environment was active (_FILE_OFFSET_BITS == 64). ** In both Solaris 11.4 and Illumos, this restriction was lifted for structured /proc. So one has to be careful always to define _STRUCTURED_PROC=1 when testing for or using <sys/procfs.h> on Solaris. As the errors above show, this isn't always the case in binutils-gdb right now. Also one may need to disable large-file support for 32-bit compilations on Solaris. config/largefile.m4 meant to do this by wrapping the AC_SYS_LARGEFILE autoconf macro with appropriate checks, yielding ACX_LARGEFILE. Unfortunately the macro doesn't always succeed because it neglects the _STRUCTURED_PROC part. To make things even worse, since GCC 9 g++ predefines _FILE_OFFSET_BITS=64 on Solaris. So even if largefile.m4 deciced not to enable large-file support, this has no effect, breaking the gdb build. This patch addresses all this as follows: * All tests for the <sys/procfs.h> header are made with _STRUCTURED_PROC=1, the definition going into the various config.h files instead of having to make them (and sometimes failing) in the affected sources. * To cope with the g++ predefine of _FILE_OFFSET_BITS=64, -U_FILE_OFFSET_BITS is added to various *_CPPFLAGS variables. It had been far easier to have just #undef _FILE_OFFSET_BITS in config.h, but unfortunately such a construct in config.in is commented by config.status irrespective of indentation and whitespace if large-file support is disabled. I found no way around this and putting the #undef in several global headers for bfd, binutils, ld, and gdb seemed way more invasive. * Last, the applicability check in largefile.m4 was modified only to disable largefile support if really needed. To do so, it checks if <sys/procfs.h> compiles with _FILE_OFFSET_BITS=64 defined. If it doesn't, the disabling only happens if gdb exists in-tree and isn't disabled, otherwise (building binutils from a tarball), there's no conflict. What initially confused me was the check for $plugins here, which originally caused the disabling not to take place. Since AC_PLUGINGS does enable plugin support if <dlfcn.h> exists (which it does on Solaris), the disabling never happened. I could find no explanation why the linker plugin needs large-file support but thought it would be enough if gld and GCC's lto-plugin agreed on the _FILE_OFFSET_BITS value. Unfortunately, that's not enough: lto-plugin uses the simple-object interface from libiberty, which includes off_t arguments. So to fully disable large-file support would mean also disabling it in libiberty and its users: gcc and libstdc++-v3. This seems highly undesirable, so I decided to disable the linker plugin instead if large-file support won't work. The patch allows binutils+gdb to build on i386-pc-solaris2.11 (both Solaris 11.3 and 11.4, using GCC 9.3.0 which is the worst case due to predefined _FILE_OFFSET_BITS=64). Also regtested on amd64-pc-solaris2.11 (again on Solaris 11.3 and 11.4), x86_64-pc-linux-gnu and i686-pc-linux-gnu. config: * largefile.m4 (ACX_LARGEFILE) <sparc-*-solaris*|i?86-*-solaris*>: Check for <sys/procfs.h> incompatilibity with large-file support on Solaris. Only disable large-file support and perhaps plugins if needed. Set, substitute LARGEFILE_CPPFLAGS if so. bfd: * bfd.m4 (BFD_SYS_PROCFS_H): New macro. (BFD_HAVE_SYS_PROCFS_TYPE): Require BFD_SYS_PROCFS_H. Don't define _STRUCTURED_PROC. (BFD_HAVE_SYS_PROCFS_TYPE_MEMBER): Likewise. * elf.c [HAVE_SYS_PROCFS_H] (_STRUCTURED_PROC): Don't define. * configure.ac: Use BFD_SYS_PROCFS_H to check for <sys/procfs.h>. * configure, config.in: Regenerate. * Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS. * Makefile.in, doc/Makefile.in: Regenerate. binutils: * Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS. * Makefile.in, doc/Makefile.in: Regenerate. * configure: Regenerate. gas: * Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS. * Makefile.in, doc/Makefile.in: Regenerate. * configure: Regenerate. gdb: * proc-api.c (_STRUCTURED_PROC): Don't define. * proc-events.c: Likewise. * proc-flags.c: Likewise. * proc-why.c: Likewise. * procfs.c: Likewise. * Makefile.in (INTERNAL_CPPFLAGS): Add LARGEFILE_CPPFLAGS. * configure, config.in: Regenerate. gdbserver: * configure, config.in: Regenerate. gdbsupport: * Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS. * common.m4 (GDB_AC_COMMON): Use BFD_SYS_PROCFS_H to check for <sys/procfs.h>. * Makefile.in: Regenerate. * configure, config.in: Regenerate. gnulib: * configure.ac: Run ACX_LARGEFILE before gl_EARLY. * configure: Regenerate. gprof: * Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS. * Makefile.in: Regenerate. * configure: Regenerate. ld: * Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS. * Makefile.in: Regenerate. * configure: Regenerate.
2020-07-27[gdb/build] Fix typo sys/sockets.h -> sys/socket.hTom de Vries1-3/+0
I'm running into a build breaker: ... src/gdb/ser-tcp.c:65:13: error: conflicting declaration ‘typedef int socklen_t’ 65 | typedef int socklen_t; | ^~~~~~~~~ In file included from ../gnulib/import/unistd.h:40, from /home/vries/gdb_versions/devel/src/gdb/../gnulib/import/pathmax.h:42, from /home/vries/gdb_versions/devel/src/gdb/../gdbsupport/common-defs.h:120, from src/gdb/defs.h:28, from src/gdb/ser-tcp.c:20: /usr/include/unistd.h:277:21: note: previous declaration as ‘typedef __socklen_t socklen_t’ 277 | typedef __socklen_t socklen_t; | ^~~~~~~~~ ... after commit 05a6b8c28b "Don't unnecessarily redefine 'socklen_t' type in MinGW builds". The root cause is a typo in gdb/configure.ac, using sys/sockets.h where sys/socket.h was meant: ... AC_CHECK_HEADERS([sys/sockets.h]) ... Fix the typo. Build and tested on x86_64-linux. gdb/ChangeLog: 2020-07-27 Tom de Vries <tdevries@suse.de> * configure.ac: Fix sys/sockets.h -> sys/socket.h typo. * config.in: Regenerate. * configure: Regenerate.
2020-07-26Don't unnecessarily redefine 'socklen_t' type in MinGW builds.Eli Zaretskii1-0/+6
The original configure-time tests in gdb/ and gdbserver/ failed to detect that 'socklen_t' is defined in MinGW headers because the test program included only sys/socket.h, which is absent in MinGW system headers. However on MS-Windows this data type is declared in another header, ws2tcpip.h. The modified test programs try using ws2tcpip.h if sys/socket.h is unavailable. Thanks to Joel Brobecker who helped me regenerate the configure scripts and the config.in files. gdb/ChangeLog: 2020-07-26 Eli Zaretskii <eliz@gnu.org> * configure.ac (AC_CHECK_HEADERS): Check for sys/socket.h and ws2tcpip.h. When checking whether socklen_t type is defined, use ws2tcpip.h if it is available and sys/socket.h isn't. * configure: Regenerate. * config.in: Regenerate. gdbserver/ChangeLog: 2020-07-26 Eli Zaretskii <eliz@gnu.org> * configure.ac (AC_CHECK_HEADERS): Add ws2tcpip.h. When checking whether socklen_t type is defined, use ws2tcpip.h if it is available and sys/socket.h isn't. * configure: Regenerate. * config.in: Regenerate.
2020-06-26Fix --enable-libctf and --disable-staticNick Alcock1-0/+3
This fixes test runs and compilation when --disable-libctf, --disable-static, or --enable-shared are passed. Changes since v2: Use GCC_ENABLE and fix indentation. Fix prototype using 'void'. Use 'unsupported' and gdb_caching_proc. Changes since v3: Adapt to upstream changes providing skip_ctf_tests. Changes since v4: Adapt to upstream changes in the seven months (!) since I last looked at this. gdb/ChangeLog * configure.ac: Add --enable-libctf: handle --disable-static properly. * acinclude.m4: sinclude ../config/enable.m4. * Makefile.in (aclocal_m4_deps): Adjust accordingly. (LIBCTF): Substitute in. (CTF_DEPS): New, likewise. (CLIBS): libctf needs symbols from libbfd: move earlier. (CDEPS): Use CTF_DEPS, not LIBCTF, now LIBCTF can include rpath flags. * ctfread.c: Surround in ENABLE_LIBCTF. (elfctf_build_psymtabs) [!ENABLE_LIBCTF]: New stub. * configure: Regenerate. * config.in: Likewise. gdb/testsuite/ChangeLog * configure.ac: Add --enable-libctf. * aclocal.m4: sinclude ../config/enable.m4. * Makefile.in (site.exp): Add enable_libctf to site.exp. * lib/gdb.exp (skip_ctf_tests): Use it. * gdb.base/ctf-constvars.exp: Error message tweak. * gdb.base/ctf-ptype.exp: Likewise. * configure: Regenerate.
2020-04-27gdb, gdbserver: remove configure check for fs_base/gs_base in user_regs_structSimon Marchi1-6/+0
I recently stumbled on this code mentioning Linux kernel 2.6.25, and thought it could be time for some spring cleaning (newer GDBs probably don't need to supports 12-year old kernels). I then found that the "legacy" case is probably broken anyway, which gives an even better motivation for its removal. In short, this patch removes the configure checks that check if user_regs_struct contains the fs_base/gs_base fields and adjusts all uses of the HAVE_STRUCT_USER_REGS_STRUCT_{FS,GS}_BASE macros. The longer explanation/rationale follows. Apparently, Linux kernels since 2.6.25 (that's from 2008) have been reliably providing fs_base and gs_base as part of user_regs_struct. Commit df5d438e33d7 in the Linux kernel [1] seems related. This means that we can get these values by reading registers with PTRACE_GETREGS. Previously, these values were obtained using a separate PTRACE_ARCH_PRCTL ptrace call. First, I'm not even sure the configure check was really right in the first place. The user_regs_struct used by GDB comes from /usr/include/x86_64-linux-gnu/sys/user.h (or equivalent on other distros) and is provided by glibc. glibc has had the fs_base/gs_base fields in there for a very long time, at least since this commit from 2001 [2]. The Linux kernel also has its version of user_regs_struct, which I think was exported to user-space at some point. It included the fs_base/gs_base fields since at least this 2002 commit [3]. In any case, my conclusion is that the fields were there long before the aforementioned Linux kernel commit. The kernel commit didn't add these fields, it only made sure that they have reliable values when obtained with PTRACE_GETREGS. So, checking for the presence of the fs_base/gs_base fields in struct user_regs_struct doesn't sound like a good way of knowing if we can reliably get the fs_base/gs_base values from PTRACE_GETREGS. My guess is that if we were using that strategy on a < 2.6.25 kernel, things would not work correctly: - configure would find that the user_regs_struct has the fs_base/gs_base fields (which are probided by glibc anyway) - we would be reading the fs_base/gs_base values using PTRACE_GETREGS, for which the kernel would provide unreliable values Second, I have tried to see how things worked by forcing GDB to not use fs_base/gs_base from PTRACE_GETREGS (forcing it to use the "legacy" code, by configuring with ac_cv_member_struct_user_regs_struct_gs_base=no ac_cv_member_struct_user_regs_struct_fs_base=no Doing so breaks writing registers back to the inferior. For example, calling an inferior functions gives an internal error: (gdb) p malloc(10) /home/smarchi/src/binutils-gdb/gdb/i387-tdep.c:1408: internal-error: invalid i387 regnum 152 The relevant last frames where this error happens are: #8 0x0000563123d262fc in internal_error (file=0x563123e93fd8 "/home/smarchi/src/binutils-gdb/gdb/i387-tdep.c", line=1408, fmt=0x563123e94482 "invalid i387 regnum %d") at /home/smarchi/src/binutils-gdb/gdbsupport/errors.cc:55 #9 0x0000563123047d0d in i387_collect_xsave (regcache=0x5631269453f0, regnum=152, xsave=0x7ffd38402a20, gcore=0) at /home/smarchi/src/binutils-gdb/gdb/i387-tdep.c:1408 #10 0x0000563122c69e8a in amd64_collect_xsave (regcache=0x5631269453f0, regnum=152, xsave=0x7ffd38402a20, gcore=0) at /home/smarchi/src/binutils-gdb/gdb/amd64-tdep.c:3448 #11 0x0000563122c5e94c in amd64_linux_nat_target::store_registers (this=0x56312515fd10 <the_amd64_linux_nat_target>, regcache=0x5631269453f0, regnum=152) at /home/smarchi/src/binutils-gdb/gdb/amd64-linux-nat.c:335 #12 0x00005631234c8c80 in target_store_registers (regcache=0x5631269453f0, regno=152) at /home/smarchi/src/binutils-gdb/gdb/target.c:3485 #13 0x00005631232e8df7 in regcache::raw_write (this=0x5631269453f0, regnum=152, buf=0x56312759e468 "@\225\372\367\377\177") at /home/smarchi/src/binutils-gdb/gdb/regcache.c:765 #14 0x00005631232e8f0c in regcache::cooked_write (this=0x5631269453f0, regnum=152, buf=0x56312759e468 "@\225\372\367\377\177") at /home/smarchi/src/binutils-gdb/gdb/regcache.c:778 #15 0x00005631232e75ec in regcache::restore (this=0x5631269453f0, src=0x5631275eb130) at /home/smarchi/src/binutils-gdb/gdb/regcache.c:283 #16 0x0000563123083fc4 in infcall_suspend_state::restore (this=0x5631273ed930, gdbarch=0x56312718cf20, tp=0x5631270bca90, regcache=0x5631269453f0) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:9103 #17 0x0000563123081eed in restore_infcall_suspend_state (inf_state=0x5631273ed930) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:9151 The problem seems to be that amd64_linux_nat_target::store_registers calls amd64_native_gregset_supplies_p to know whether gregset provides fs_base. When !HAVE_STRUCT_USER_REGS_STRUCT_FS_BASE, amd64_native_gregset_supplies_p returns false. store_registers therefore assumes that it must be an "xstate" register. This is of course wrong, and that leads to the failed assertion when i387_collect_xsave doesn't recognize the register. amd64_linux_nat_target::store_registers could probably be fixed to handle this case, but I don't think it's worth it, given that it would only be to support very old kernels. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=df5d438e33d7fc914ba9b6e0d6b019a8966c5fcc [2] https://sourceware.org/git/?p=glibc.git;a=commit;h=c9cf6ddeebb7bb [3] https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=88e4bc32686ebd0b1111a94f93eba2d334241f68 gdb/ChangeLog: * configure.ac: Remove check for fs_base/gs_base in user_regs_struct. * configure: Re-generate. * config.in: Re-generate. * amd64-nat.c (amd64_native_gregset_reg_offset): Adjust. * amd64-linux-nat.c (amd64_linux_nat_target::fetch_registers, amd64_linux_nat_target::store_registers, ps_get_thread_area, ): Adjust. gdbserver/ChangeLog: * configure.ac: Remove check for fs_base/gs_base in user_regs_struct. * configure: Re-generate. * config.in: Re-generate. * linux-x86-low.cc (x86_64_regmap, x86_fill_gregset, x86_store_gregset): Adjust.
2020-03-20gdb: remove HAVE_DECL_PTRACESimon Marchi1-4/+0
I stumbled on this snippet in nat/gdb_ptrace.h: /* Some systems, in particular DEC OSF/1, Digital Unix, Compaq Tru64 or whatever it's called these days, don't provide a prototype for ptrace. Provide one to silence compiler warnings. */ #ifndef HAVE_DECL_PTRACE extern PTRACE_TYPE_RET ptrace(); #endif I believe this is unnecessary today and should be removed. First, the comment only mentions OSes we don't support (and to be honest, I had never even heard of). But most importantly, in C++, a declaration with empty parenthesis declares a function that accepts no arguments, unlike in C. So if this declaration was really used, GDB wouldn't build, since all ptrace call sites pass some arguments. Since we haven't heard anything about this causing some build failures since we have transitioned to C++, I conclude that it's not used. This patch removes it as well as the corresponding configure check. gdb/ChangeLog: * ptrace.m4: Don't check for ptrace declaration. * config.in: Re-generate. * configure: Re-generate. * nat/gdb_ptrace.h: Don't declare ptrace if HAVE_DECL_PTRACE is not defined. gdbserver/ChangeLog: * config.in: Re-generate. * configure: Re-generate. gdbsupport/ChangeLog: * config.in: Re-generate. * configure: Re-generate.
2020-02-26Add debuginfod support to GDBAaron Merey1-0/+3
debuginfod is a lightweight web service that indexes ELF/DWARF debugging resources by build-id and serves them over HTTP. This patch enables GDB to query debuginfod servers for separate debug files and source code when it is otherwise not able to find them. GDB can be built with debuginfod using the --with-debuginfod configure option. This requires that libdebuginfod be installed and found at configure time. debuginfod is packaged with elfutils, starting with version 0.178. For more information see https://sourceware.org/elfutils/. Tested on x86_64 Fedora 31. gdb/ChangeLog: 2020-02-26 Aaron Merey <amerey@redhat.com> * Makefile.in: Handle optional debuginfod support. * NEWS: Update. * README: Add --with-debuginfod summary. * config.in: Regenerate. * configure: Regenerate. * configure.ac: Handle optional debuginfod support. * debuginfod-support.c: debuginfod helper functions. * debuginfod-support.h: Ditto. * doc/gdb.texinfo: Add --with-debuginfod to configure options summary. * dwarf2/read.c (dwarf2_get_dwz_file): Query debuginfod servers when a dwz file cannot be found. * elfread.c (elf_symfile_read): Query debuginfod servers when a debuginfo file cannot be found. * source.c (open_source_file): Query debuginfod servers when a source file cannot be found. * top.c (print_gdb_configuration): Include --{with,without}-debuginfod in the output. gdb/testsuite/ChangeLog: 2020-02-26 Aaron Merey <amerey@redhat.com> * gdb.debuginfod: New directory for debuginfod tests. * gdb.debuginfod/main.c: New test file. * gdb.debuginfod/fetch_src_and_symbols.exp: New tests.
2020-02-20gdb: Allow more control over where to find python librariesAndrew Burgess1-0/+8
The motivation behind this commit is to make it easier to bundle the Python *.py library files with GDB when statically linking GDB against libpython. The Python files will be manually added into the GDB installation tree, and GDB should be able to find them at run-time. The installation tree will look like this: . |-- bin/ |-- include/ |-- lib/ | `-- python3.8/ `-- share/ The benefit here is that the entire installation tree can be bundled into a single archive and copied to another machine with a different version of Python installed, and GDB will still work, including its Python support. In use the new configure options would be used something like this, first build and install a static Python library: mkdir python cd python # Clone or download Python into a src/ directory. mkdir build export PYTHON_INSTALL_PATH=$PWD/install cd build ../src/configure --disable-shared --prefix=$PYTHON_INSTALL_PATH make make install Now build and install GDB: mkdir binutils-gdb cd binutils-gdb # Clone or download GDB into a src/ directory. mkdir build export GDB_INSTALL_DIR=$PWD/install cd build ../src/configure \ --prefix=$GDB_INSTALL_DIR \ --with-python=$PYTHON_INSTALL_PATH/bin/python3 \ --with-python-libdir=$GDB_INSTALL_DIR/lib make all-gdb make install-gdb Finally, copy the Python libraries into the GDB install: cp -r $PYTHON_INSTALL_DIR/lib/python3.8/ $GDB_INSTALL_DIR/lib After this the Python src, build, and install directories are no longer needed and can be deleted. If the new --with-python-libdir option is not used then the existing behaviour is left unchanged, GDB will look for the Python libraries in the lib/ directory within the python path. The concatenation of the python prefix and the string 'lib/' is now done at configure time, rather than at run time in GDB as it was previous, however, this was never something that the user had dynamic control over, so there's no loss of functionality. gdb/ChangeLog: * config.in: Regenerate. * configure: Regenerate. * configure.ac: Add --with-python-libdir option. * main.c: Use WITH_PYTHON_LIBDIR.
2019-12-10Replace the remaining uses of strerror with safe_strerrorChristian Biesinger1-4/+0
To do that, this patch makes IPA compile safe-strerror as well. Because it doesn't use Gnulib, it calls the Glibc version of strerror_r directly. Consequently this patch also removes the configure checks for strerror. gdb/ChangeLog: 2019-12-10 Christian Biesinger <cbiesinger@google.com> * config.in: Regenerate. * configure: Regenerate. * gdbsupport/agent.c (gdb_connect_sync_socket): Call safe_strerror instead of strerror. * gdbsupport/common.m4: Don't check for strerror. * gdbsupport/safe-strerror.c: Support both the glibc version of strerror_r and the XSI version. gdb/gdbserver/ChangeLog: 2019-12-10 Christian Biesinger <cbiesinger@google.com> * Makefile.in: Add safe-strerror.c to gdbreplay and IPA, and change UNDO_GNULIB_CFLAGS to undo strerror_r instead of strerror. * config.in: Regenerate. * configure: Regenerate. * configure.ac: Don't check for strerror. * linux-i386-ipa.c (initialize_fast_tracepoint_trampoline_buffer): Call safe_strerror instead of strerror. * server.h (strerror): Remove this now-unnecessary declaration. * tracepoint.c (init_named_socket): Call safe_strerror instead of strerror. (gdb_agent_helper_thread): Likewise. * utils.c (perror_with_name): Likewise. Change-Id: I74848f072dcde75cb55c435ef9398dc8f958cd73
2019-11-26Set names of worker threadsTom Tromey1-0/+3
This adds some configury so that gdb can set the names of worker threads. This makes them show up more nicely when debugging gdb itself. 2019-11-26 Tom Tromey <tom@tromey.com> * gdbsupport/thread-pool.c (thread_pool::set_thread_count): Set name of worker thread. * gdbsupport/common.m4 (GDB_AC_COMMON): Check for pthread_setname_np. * configure, config.in: Rebuild. gdb/gdbserver/ChangeLog 2019-11-26 Tom Tromey <tom@tromey.com> * configure, config.in: Rebuild. Change-Id: I60473d65ae9ae14d8c56ddde39684240c16aaf35
2019-11-26Add RAII class for blocking gdb signalsTom Tromey1-0/+3
This adds configury support and an RAII class that can be used to temporarily block signals that are used by gdb. (This class is not used in this patch, but it split out for easier review.) The idea of this patch is that these signals should only be delivered to the main thread. So, when creating a background thread, they are temporarily blocked; the blocked state is inherited by the new thread. The sigprocmask man page says: The use of sigprocmask() is unspecified in a multithreaded process; see pthread_sigmask(3). This patch changes gdb to use pthread_sigmask when appropriate, by introducing a convenience define. I've updated gdbserver as well, because I had to touch gdbsupport, and because the threading patches will make it link against the thread library. I chose not to touch the NTO code, because I don't know anything about that platform and because I cannot test it. Finally, this modifies an existing spot in the Guile layer to use the new facility. gdb/ChangeLog 2019-11-26 Tom Tromey <tom@tromey.com> * gdbsupport/signals-state-save-restore.c (original_signal_mask): Remove comment. (save_original_signals_state, restore_original_signals_state): Use gdb_sigmask. * linux-nat.c (block_child_signals, restore_child_signals_mask) (_initialize_linux_nat): Use gdb_sigmask. * guile/guile.c (_initialize_guile): Use block_signals. * Makefile.in (HFILES_NO_SRCDIR): Add gdb-sigmask.h. * gdbsupport/gdb-sigmask.h: New file. * event-top.c (async_sigtstp_handler): Use gdb_sigmask. * cp-support.c (gdb_demangle): Use gdb_sigmask. * gdbsupport/common.m4 (GDB_AC_COMMON): Check for pthread_sigmask. * configure, config.in: Rebuild. * gdbsupport/block-signals.h: New file. gdb/gdbserver/ChangeLog 2019-11-26 Tom Tromey <tom@tromey.com> * remote-utils.c (block_unblock_async_io): Use gdb_sigmask. * linux-low.c (linux_wait_for_event_filtered, linux_async): Use gdb_sigmask. * configure, config.in: Rebuild. Change-Id: If3f37dc57dd859c226e9e4d79458a0514746e8c6
2019-11-26Add configure check for std::threadTom Tromey1-0/+10
This adds a configure check for std::thread. This is needed because std::thread is not available on some systems, like some versions of mingw and DJGPP. This also adds configury to make sure that a threaded gdb links against the correct threading library (-lpthread or the like), and passes the right flags (e.g., -pthread) to the compilations. Note that this also links gdbserver against the thread library. This is not strictly necessary at this point in the series, but a later patch will change gdbsupport to use pthread_sigmask, at which point this will be needed. gdb/ChangeLog 2019-11-26 Tom Tromey <tom@tromey.com> * acinclude.m4: Include ax_pthread.m4. * Makefile.in (PTHREAD_CFLAGS, PTHREAD_LIBS): New variables. (INTERNAL_CFLAGS_BASE): Use PTHREAD_CFLAGS. (CLIBS): Use PTHREAD_LIBS. (aclocal_m4_deps): Add ax_pthread.m4. * config.in, configure: Rebuild. * gdbsupport/common.m4 (GDB_AC_COMMON): Check for std::thread. gdb/gdbserver/ChangeLog 2019-11-26 Tom Tromey <tom@tromey.com> * Makefile.in (PTHREAD_CFLAGS, PTHREAD_LIBS): New variables. (INTERNAL_CFLAGS_BASE): Use PTHREAD_CFLAGS. (GDBSERVER_LIBS): Use PTHREAD_LIBS. * acinclude.m4: Include ax_pthread.m4. * config.in, configure: Rebuild. Change-Id: I00ec55db6077f2615421a93461fc3be57e916aa0
2019-11-15Import the strerror_r-posix module and use it in GDB.Christian Biesinger1-3/+0
Makes sure to assign the return value of strerror_r to an int, so that we get a compile error if we accidentally get the wrong version. gdb/ChangeLog: 2019-11-15 Christian Biesinger <cbiesinger@google.com> * config.in: Regenerate. * configure: Regenerate. * gdbsupport/common.m4: No longer check for strerror_r. * gdbsupport/posix-strerror.c (safe_strerror): Always call the POSIX version of strerror_r, now that gnulib provides it if necessary. gdb/gdbserver/ChangeLog: 2019-11-15 Christian Biesinger <cbiesinger@google.com> * config.in: Regenerate. * configure: Regenerate. gnulib/ChangeLog: 2019-11-15 Christian Biesinger <cbiesinger@google.com> * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * config.in: Regenerate. * configure: Regenerate. * import/Makefile.am: Update. * import/Makefile.in: Regenerate. * import/extra/config.rpath: New file. * import/glthread/lock.c: New file. * import/glthread/lock.h: New file. * import/glthread/threadlib.c: New file. * import/m4/gnulib-cache.m4: Update. * import/m4/gnulib-comp.m4: Update. * import/m4/lib-ld.m4: New file. * import/m4/lib-link.m4: New file. * import/m4/lib-prefix.m4: New file. * import/m4/lock.m4: New file. * import/m4/strerror_r.m4: New file. * import/m4/threadlib.m4: New file. * import/strerror_r.c: New file. * update-gnulib.sh: Import strerror_r-posix. Change-Id: I5cfeb12a5203a4cd94a78581541e6085a68685c3
2019-10-31Regenerate config.inChristian Biesinger1-0/+3
I forgot to do this in the last commit (b231e86ac9608056ea837e24d42a878927f5787a) gdb/ChangeLog: 2019-10-31 Christian Biesinger <cbiesinger@google.com> * config.in: Regenerate. Change-Id: I60946ffd853a59469c35f19ef8012ac6ea88a31c
2019-10-29Load system gdbinit files from a directoryChristian Biesinger1-0/+7
Adds a configure option --with-system-gdbinit-dir to specify a directory in which to look for gdbinit files. All files in this directory are loaded on startup (subject to -n/-nx as usual) as long as the extension matches a known and enabled scripting language (.gdb/.py/.scm). This also changes get_ext_lang_of_file to support ".gdb" files, similar to get_ext_lang_defn's handling of EXT_LANG_GDB. gdb/ChangeLog: 2019-10-29 Christian Biesinger <cbiesinger@google.com> * NEWS: Mention new --with-system-gdbinit-dir option. * config.in: Regenerate. * configure: Regenerate. * configure.ac: Add new option --with-system-gdbinit-dir. * extension.c (get_ext_lang_of_file): Return extension_language_gdb for a ".gdb" suffix. * main.c (get_init_files): Change system_gdbinit argument to a vector and return the files in SYSTEM_GDBINIT_DIR in addition to SYSTEM_GDBINIT. (captured_main_1): Update. (print_gdb_help): Update. * top.c (print_gdb_configuration): Also print the value of SYSTEM_GDBINIT_DIR. gdb/doc/ChangeLog: 2019-10-29 Christian Biesinger <cbiesinger@google.com> * Makefile.in: Also set SYSTEM_GDBINIT_DIR for the info manual generation. * gdb.texinfo (many sections): Document new --with-system-gdbinit-dir option. Change-Id: If233859ecc21bc6421d589b37cd658a3c7d030f2
2019-10-24Simplify Python checks in configure.acChristian Biesinger1-6/+0
The version checking code is not necessary. It is only used to define HAVE_LIBPYTHON2_6 or HAVE_LIBPYTHON2_7, which is not used anywhere. If a version check is desired, the PY_{MAJOR,MINOR}_VERSION macro from the Python headers can be (and is) used, which does not require updating configure.ac whenever a new Python version is released. gdb/ChangeLog: 2019-10-24 Christian Biesinger <cbiesinger@google.com> * config.in: Regenerate. * configure: Regenerate. * configure.ac: Remove the code that uses sed to get the python version and defines HAVE_LIBPYTHON2_6 / HAVE_LIBPYTHON2_7. Change-Id: I07073870d9040c2bc8519882c8b3c1368edd4513
2019-10-22Use libxxhash for hashing, if presentChristian Biesinger1-0/+3
XXHash is faster than htab_hash_string: ------------------------------------------------------------ Benchmark Time CPU Iterations ------------------------------------------------------------ BM_xxh3 11 ns 11 ns 65887249 BM_xxh32 19 ns 19 ns 36511877 BM_xxh64 16 ns 16 ns 42964585 BM_hash_string 182 ns 182 ns 3853125 BM_iterative_hash 77 ns 77 ns 9087638 Unfortunately, XXH3 is still experimental (see https://github.com/Cyan4973/xxHash#user-content-new-experimental-hash-algorithm) However, regular XXH64 is still a lot faster than htab_hash_string per my benchmark above. I used the following string for the benchmark: static constexpr char str[] = "_ZZZL13make_gdb_typeP7gdbarchP10tdesc_typeEN16gdb_type_creator19make_gdb_type_flagsEPK22tdesc_type_with_fieldsE19__PRETTY_FUNCTION__"; htab_hash_string is currently 4.35% + 7.98% (rehashing) of gdb startup when attaching to Chrome's content_shell. An additional 5.21% is spent in msymbol_hash, which does not use this hash function. Unfortunately, since it has to lowercase the string, it can't use this hash function. BM_msymbol_hash 52 ns 52 ns 13281495 It may be worth investigating if strlen+XXHash is still faster than htab_hash_string, which would make it easier to use in more places. Debian ships xxhash as libxxhash{0,-dev}. Fedora ships it as xxhash-devel. gdb/ChangeLog: 2019-10-22 Christian Biesinger <cbiesinger@google.com> * Makefile.in: Link with libxxhash. * config.in: Regenerate. * configure: Regenerate. * configure.ac: Search for libxxhash. * utils.c (fast_hash): Use xxhash if present. Change-Id: Icab218388b9f829522ed3977f04301ae6d4fc4ca
2019-08-06[PR build/24886] disable glibc mcheck supportFrank Ch. Eigler1-3/+0
This patch drops gdb's configury support for glibc's mcheck function. It has been observed to cause false abort()s, because it is thread-unsafe yet interposes every malloc/free operation. So if any library transitively used by gdb also uses threads, then these functions can easily corrupt their own checking data. These days, gcc ASAN and valgrind provide high quality checking, and mcheck is apparently itself being slowly deprecated. So, let's stop linking to it. Attached patch drops the autoconf/Makefile machinery for both gdb and gdbserver. No testsuite-visible impact. IMHO not worth mentioning in NEWS. See also: https://sourceware.org/bugzilla/show_bug.cgi?id=9939 gdb/ChangeLog PR build/24886 * configure.ac: Drop enable-libmcheck support. * configure, config.in: Rebuild. * libmcheck.m4: Remove. * acinclude.m4: Don't include it. * Makefile.in: Don't distribute it. * top.c (print_gdb_configuration): Don't mention it. gdb/gdbserver/ChangeLog PR build/24886 * configure.ac: Drop enable-libmcheck support. * configure, config.in: Rebuild. * acinclude.m4: Don't include it.
2019-02-27Remove Python 2.4 and 2.5 supportTom Tromey1-6/+0
This removes all the remainings spots I could find that work around issues in Python 2.4 and 2.5. I don't have a good way to test that Python 2.6 still works. Tested by the buildbot. gdb/ChangeLog 2019-02-27 Tom Tromey <tromey@adacore.com> * config.in, configure: Rebuild. * configure.ac (HAVE_LIBPYTHON2_4, HAVE_LIBPYTHON2_5): Never define. * python/py-value.c: Remove Python 2.4 workaround. * python/py-utils.c (gdb_pymodule_addobject): Remove Python 2.4 workaround. * python/py-type.c (convert_field, gdbpy_initialize_types): Remove Python 2.4 workaround. * python/python-internal.h: Remove Python 2.4 comment. (Py_ssize_t): Don't define. (PyVarObject_HEAD_INIT, Py_TYPE): Don't define. (gdb_Py_DECREF): Remove Python 2.4 workaround. (gdb_PyObject_GetAttrString, PyObject_GetAttrString): Remove. (gdb_PyObject_HasAttrString, PyObject_HasAttrString): Remove. * python/python.c (do_start_initialization): Remove Python 2.4 workaround. * python/py-prettyprint.c (class dummy_python_frame): Remove. (print_children): Remove Python 2.4 workaround. * python/py-inferior.c (buffer_procs): Remove Python 2.4 workaround. (CHARBUFFERPROC_NAME): Remove. * python/py-breakpoint.c (gdbpy_initialize_breakpoints): Remove Python 2.4 workaround. gdb/testsuite/ChangeLog 2019-02-27 Tom Tromey <tromey@adacore.com> * lib/gdb.exp (skip_python_tests_prompt): Don't check for Python 2.4. * gdb.python/py-finish-breakpoint.exp: Remove Python 2.4 workaround. gdb/ChangeLog 2019-02-27 Tom Tromey <tromey@adacore.com> * config.in, configure: Rebuild. * configure.ac (HAVE_LIBPYTHON2_4, HAVE_LIBPYTHON2_5): Never define. * python/py-value.c: Remove Python 2.4 workaround. * python/py-utils.c (gdb_pymodule_addobject): Remove Python 2.4 workaround. * python/py-type.c (convert_field, gdbpy_initialize_types): Remove Python 2.4 workaround. * python/python-internal.h: Remove Python 2.4 comment. (Py_ssize_t): Don't define. (PyVarObject_HEAD_INIT, Py_TYPE): Don't define. (gdb_Py_DECREF): Remove Python 2.4 workaround. (gdb_PyObject_GetAttrString, PyObject_GetAttrString): Remove. (gdb_PyObject_HasAttrString, PyObject_HasAttrString): Remove. * python/python.c (do_start_initialization): Remove Python 2.4 workaround. * python/py-prettyprint.c (class dummy_python_frame): Remove. (print_children): Remove Python 2.4 workaround. * python/py-inferior.c (buffer_procs): Remove Python 2.4 workaround. (CHARBUFFERPROC_NAME): Remove. * python/py-breakpoint.c (gdbpy_initialize_breakpoints): Remove Python 2.4 workaround.
2018-12-28Highlight source code using GNU Source HighlightTom Tromey1-0/+3
This changes gdb to highlight source using GNU Source Highlight, if it is available. This affects the output of the "list" command and also the TUI source window. No new test because I didn't see a way to make it work when Source Highlight is not found. gdb/ChangeLog 2018-12-28 Tom Tromey <tom@tromey.com> * utils.h (can_emit_style_escape): Declare. * utils.c (can_emit_style_escape): No longer static. * cli/cli-style.c (set_style_enabled): New function. (_initialize_cli_style): Use it. * tui/tui-winsource.c (tui_show_source_line): Use tui_puts. (tui_alloc_source_buffer): Change how source lines are allocated. * tui/tui-source.c (copy_source_line): New function. (tui_set_source_content): Use source cache. * tui/tui-io.h (tui_puts): Update. * tui/tui-io.c (tui_puts_internal): Add window parameter. (tui_puts): Likewise. (tui_redisplay_readline): Update. * tui/tui-data.c (free_content_elements): Change how source window contents are freed. * source.c (forget_cached_source_info): Clear the source cache. (print_source_lines_base): Use the source cache. * source-cache.h: New file. * source-cache.c: New file. * configure.ac: Check for GNU Source Highlight library. * configure: Update. * config.in: Update. * Makefile.in (SRCHIGH_LIBS, SRCHIGH_CFLAGS): New variables. (INTERNAL_CFLAGS_BASE): Add SRCHIGH_CFLAGS. (CLIBS): Add SRCHIGH_LIBS. (COMMON_SFILES): Add source-cache.c. (HFILES_NO_SRCDIR): Add source-cache.h.
2018-12-28Make ANSI terminal escape sequences work in TUITom Tromey1-0/+3
PR tui/14126 notes that ANSI terminal escape sequences don't affect the colors shown in the TUI. A simple way to see this is to try the extended-prompt example from the gdb manual. Curses does not pass escape sequences through to the terminal. Instead, it replaces non-printable characters with a visible representation, for example "^[" for the ESC character. This patch fixes the problem by adding a simple ANSI terminal sequence parser to gdb. These sequences are decoded and those that are recognized are turned into the appropriate curses calls. The curses approach to color handling is unusual and so there are some oddities in the implementation. Standard curses has no notion of the default colors of the terminal. So, if you set the foreground color, it is not possible to reset it -- you have to pick some other color. ncurses provides an extension to handle this, so this patch updates configure and uses it when available. Second, in curses, colors always come in pairs: you cannot set just the foreground. This patch handles this by tracking actually-used pairs of colors and keeping a table of these for reuse. Third, there are a limited number of such pairs available. In this patch, if you try to use too many color combinations, gdb will just ignore some color changes. Finally, in addition to limiting the number of color pairs, curses also limits the number of colors. This means that, when using extended 8- or 24-bit color sequences, it may be possible to exhaust the curses color table. I am very sour on the curses design now. I do not know how to write a test for this, so I did not. gdb/ChangeLog 2018-12-28 Tom Tromey <tom@tromey.com> PR tui/14126: * tui/tui.c (tui_enable): Call start_color and use_default_colors. * tui/tui-io.c (struct color_pair): New. (color_pair_map, last_color_pair, last_style): New globals. (tui_setup_io): Clean up color map when shutting down. (curses_colors): New constant. (get_color_pair, apply_ansi_escape): New functions. (tui_write): Rewrite. (tui_puts_internal): New function, from tui_puts. Add "height" parameter. (tui_puts): Use tui_puts_internal. (tui_redisplay_readline): Use tui_puts_internal. (_initialize_tui_io): New function. (color_map): New globals. (get_color): New function. * configure.ac: Check for use_default_colors. * config.in, configure: Rebuild.
2018-11-01Import mkdtemp gnulib module, fix mingw buildSimon Marchi1-3/+0
Building with mingw currently fails: CXX unittests/mkdir-recursive-selftests.o /home/emaisin/src/binutils-gdb/gdb/unittests/mkdir-recursive-selftests.c: In function ‘void selftests::mkdir_recursive::test()’: /home/emaisin/src/binutils-gdb/gdb/unittests/mkdir-recursive-selftests.c:49:20: error: ‘mkdtemp’ was not declared in this scope if (mkdtemp (base) == NULL) ^ Commit e418a61a67a ("Move mkdir_recursive to common/filestuff.c") moved this code, but also removed the HAVE_MKDTEMP guard which prevented the mkdtemp call to be compiled on mingw. We can either put back the HAVE_MKDTEMP ifdef, or import the gnulib mkdtemp module, which provides the function for mingw. Since the mkdir_recursive is susceptible to be used on mingw at some point, I think it would be nice to have it tested on mingw, so I did the latter. Once built, I tested it on Windows (copied the resulting gdb.exe on a Windows machine, ran it, and ran "maint selftest mkdir_recursive"). It failed, because the temporary directory is hardcoded to "/tmp/...". I therefore added and used a new get_standard_temp_dir function, which returns an appropriate temporary directory for the host platform. gdb/ChangeLog: * common/pathstuff.c (get_standard_temp_dir): New. * common/pathstuff.h (get_standard_temp_dir): New. * config.in: Re-generate. * configure: Re-generate. * configure.ac: Don't check for mkdtemp. * gnulib/aclocal-m4-deps.mk: Re-generate. * gnulib/aclocal.m4: Re-generate. * gnulib/config.in: Re-generate. * gnulib/configure: Re-generate. * gnulib/import/Makefile.am: Re-generate. * gnulib/import/Makefile.in: Re-generate. * gnulib/import/m4/gnulib-cache.m4: Re-generate. * gnulib/import/m4/gnulib-comp.m4: Re-generate. * gnulib/import/m4/mkdtemp.m4: New file. * gnulib/import/mkdtemp.c: New file. * gnulib/update-gnulib.sh (IMPORTED_GNULIB_MODULES): Add mkdtemp module. * unittests/mkdir-recursive-selftests.c (test): Use get_standard_temp_dir. (_initialize_mkdir_recursive_selftests): Remove HAVE_MKDTEMP ifdef. * compile/compile.c (get_compile_file_tempdir): Likewise.
2018-10-29Revert "GDB: Only build for "unix:" connections if AF_LOCAL is supported."Simon Marchi1-3/+0
This reverts commit 98a17ece013cb94cd602496b9efb92b8816b3953.
2018-10-29GDB: Only build for "unix:" connections if AF_LOCAL is supported.John Darrington1-0/+3
Commit f19c7ff839d7a32ebb48482ae7d318fb46ca823d added a new member to the prefixes array which included a use of the symbol AF_LOCAL. Unfortunately, not all systems declare this symbol. This change only compiles the "unix:" member if the system knows about AF_LOCAL. gdb/ChangeLog: * configure.ac: New test HAVE_AF_LOCAL * common/netstuff.c (parse_connection_spec) [prefixes]: Only compile "unix:" if HAVE_AF_LOCAL is true. * configure: regenerate. * config.in: regenerate.
2018-10-01Remove ancient workaroundGary Benson1-3/+0
This commit removes a workaround for a bug in glibc 2.1.3, which was released 2000-02-24 and superseded 2000-11-09. gdb/ChangeLog: * gdb_proc_service.h (gdb_prfpregset_t): Remove typedef. * proc-service.c (ps_lgetfpregs, ps_lsetfpregs): Use prfpregset_t instead of gdb_prfpregset_t. * configure.ac (PRFPREGSET_T_BROKEN): Remove check. * configure, config.in: Rebuild.
2018-10-01Add workaround from gdbserver's gdb_proc_service.h to GDBGary Benson1-0/+6
This commit adds a workaround from gdbserver's gdb_proc_service.h to GDB's. It doesn't seem to have been needed on any glibc as far back as 2001, but it's possibly required for other C libraries so I've retained it. gdb/ChangeLog: * configure.ac: Check if sys/procfs.h defines elf_fpregset_t. (AC_CHECK_HEADERS): Check for linux/elf.h. * configure, config.in: Rebuild. * gdb_proc_service.h: Include linux/elf.h if sys/procfs.h doesn't define elf_fpregset_t.
generated by cgit v1.1 at 2024-11-25 18:05:52 +0000