aboutsummaryrefslogtreecommitdiff
path: root/gdb/config.in
AgeCommit message (Collapse)AuthorFilesLines
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.
2018-07-24Remove some unnecessary declarations and configuryTom Tromey1-12/+0
configure checks for declarations of free, malloc, and realloc; but the results are only used in a single spot: utils.c. I think these checks are long since obsolete, so this patch removes them. Grepping the entire tree for these HAVE_DECL_ symbols, the only uses of possible interest to gdb come from bfd/sysdep.h; but this is not (nor should be) included by gdb. (And furthermore I think the code there is probably also obsolete.) gdb/ChangeLog 2018-07-24 Tom Tromey <tom@tromey.com> * utils.c (malloc, realloc, free): Don't declare. * configure, config.in: Rebuild. * configure.ac: Don't check for declarations of free, malloc, or realloc.
2018-06-19Bump to autoconf 2.69 and automake 1.15.1Simon Marchi1-11/+19
When trying to run the update-gnulib.sh script in gdb, I get this: Error: Wrong automake version (Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\${ <-- HERE ([^ =:+{}]+)}/ at /opt/automake/1.11.1/bin/automake line 4113.), we need 1.11.1. Aborting. Apparently, it's an issue with a regex in automake that triggers a warning starting with Perl 5.22. It has been fixed in automake 1.15.1. So I think it's a good excuse to bump the versions of autoconf and automake used in the gnulib import. And to avoid requiring multiple builds of autoconf/automake, it was suggested that we bump the required version of those tools for all binutils-gdb. For autoconf, the 2.69 version is universally available, so it's an easy choice. For automake, different distros and distro versions have different automake versions. But 1.15.1 seems to be the most readily available as a package. In any case, it's easy to build it from source. I removed the version checks from AUTOMAKE_OPTIONS and AC_PREREQ, because I don't think they are useful in our case. They only specify a lower bound for the acceptable version of automake/autoconf. That's useful if you let the user choose the version of the tool they want to use, but want to set a minimum version (because you use a feature that was introduced in that version). In our case, we force people to use a specific version anyway. For the autoconf version, we have the check in config/override.m4 that enforces the version we want. It will be one less thing to update next time we change autotools version. I hit a few categories of problems that required some changes. They are described below along with the chosen solutions. Problem 1: configure.ac:17: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms are deprecated. For more info, see: configure.ac:17: http://www.gnu.org/software/automake/manual/automake.html#Modernize-AM_005fINIT_005fAUTOMAKE-invocation Solution 1: Adjust the code based on the example at that URL. Problem 2 (in zlib/): Makefile.am: error: required file './INSTALL' not found Makefile.am: 'automake --add-missing' can install 'INSTALL' Makefile.am: error: required file './NEWS' not found Makefile.am: error: required file './AUTHORS' not found Makefile.am: error: required file './COPYING' not found Makefile.am: 'automake --add-missing' can install 'COPYING' Solution 2: Add the foreign option to AUTOMAKE_OPTIONS. Problem 3: doc/Makefile.am:20: error: support for Cygnus-style trees has been removed Solution 3: Remove the cygnus options. Problem 4: Makefile.am:656: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS') Solution 4: Rename "INCLUDES = " to "AM_CPPFLAGS += " (because AM_CPPFLAGS is already defined earlier). Problem 5: doc/Makefile.am:71: warning: suffix '.texinfo' for Texinfo files is discouraged; use '.texi' instead doc/Makefile.am: warning: Oops! doc/Makefile.am: It appears this file (or files included by it) are triggering doc/Makefile.am: an undocumented, soon-to-be-removed automake hack. doc/Makefile.am: Future automake versions will no longer place in the builddir doc/Makefile.am: (rather than in the srcdir) the generated '.info' files that doc/Makefile.am: appear to be cleaned, by e.g. being listed in CLEANFILES or doc/Makefile.am: DISTCLEANFILES. doc/Makefile.am: If you want your '.info' files to be placed in the builddir doc/Makefile.am: rather than in the srcdir, you have to use the shiny new doc/Makefile.am: 'info-in-builddir' automake option. Solution 5: Rename .texinfo files to .texi. Problem 6: doc/Makefile.am: warning: Oops! doc/Makefile.am: It appears this file (or files included by it) are triggering doc/Makefile.am: an undocumented, soon-to-be-removed automake hack. doc/Makefile.am: Future automake versions will no longer place in the builddir doc/Makefile.am: (rather than in the srcdir) the generated '.info' files that doc/Makefile.am: appear to be cleaned, by e.g. being listed in CLEANFILES or doc/Makefile.am: DISTCLEANFILES. doc/Makefile.am: If you want your '.info' files to be placed in the builddir doc/Makefile.am: rather than in the srcdir, you have to use the shiny new doc/Makefile.am: 'info-in-builddir' automake option. Solution 6: Remove the hack at the bottom of doc/Makefile.am and use the info-in-builddir automake option. Problem 7: doc/Makefile.am:35: error: required file '../texinfo.tex' not found doc/Makefile.am:35: 'automake --add-missing' can install 'texinfo.tex' Solution 7: Use the no-texinfo.tex automake option. We also have one in texinfo/texinfo.tex, not sure if we should point to that, or move it (or a newer version of it added with automake --add-missing) to top-level. Problem 8: Makefile.am:131: warning: source file 'config/tc-aarch64.c' is in a subdirectory, Makefile.am:131: but option 'subdir-objects' is disabled automake: warning: possible forward-incompatibility. automake: At least a source file is in a subdirectory, but the 'subdir-objects' automake: automake option hasn't been enabled. For now, the corresponding output automake: object file(s) will be placed in the top-level directory. However, automake: this behaviour will change in future Automake versions: they will automake: unconditionally cause object files to be placed in the same subdirectory automake: of the corresponding sources. automake: You are advised to start using 'subdir-objects' option throughout your automake: project, to avoid future incompatibilities. Solution 8: Use subdir-objects, that means adjusting references to some .o that will now be in config/. Problem 9: configure.ac:375: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2601: _AC_COMPILE_IFELSE is expanded from... ../../lib/autoconf/general.m4:2617: AC_COMPILE_IFELSE is expanded from... ../../lib/m4sugar/m4sh.m4:639: AS_IF is expanded from... ../../lib/autoconf/general.m4:2042: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:2063: AC_CACHE_CHECK is expanded from... configure.ac:375: the top level Solution 9: Use AC_LANG_SOURCE, or use proper quoting. Problem 10 (in intl/): configure.ac:7: warning: AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS /usr/share/aclocal/threadlib.m4:36: gl_THREADLIB_EARLY_BODY is expanded from... /usr/share/aclocal/threadlib.m4:29: gl_THREADLIB_EARLY is expanded from... /usr/share/aclocal/threadlib.m4:318: gl_THREADLIB is expanded from... /usr/share/aclocal/lock.m4:9: gl_LOCK is expanded from... /usr/share/aclocal/intl.m4:211: gt_INTL_SUBDIR_CORE is expanded from... /usr/share/aclocal/intl.m4:25: AM_INTL_SUBDIR is expanded from... /usr/share/aclocal/gettext.m4:57: AM_GNU_GETTEXT is expanded from... configure.ac:7: the top level Solution 10: Add AC_USE_SYSTEM_EXTENSIONS in configure.ac. ChangeLog: * libtool.m4: Use AC_LANG_SOURCE. * configure.ac: Remove AC_PREREQ, use AC_LANG_SOURCE. * README-maintainer-mode: Update version requirements. * ar-lib: New file. * test-driver: New file. * configure: Re-generate. bfd/ChangeLog: * Makefile.am (AUTOMAKE_OPTIONS): Remove 1.11. (INCLUDES): Rename to ... (AM_CPPFLAGS): ... this. * configure.ac: Remove AC_PREREQ. * doc/Makefile.am (AUTOMAKE_OPTIONS): Remove 1.9, cygnus, add info-in-builddir no-texinfo.tex. (info_TEXINFOS): Rename bfd.texinfo to bfd.texi. * doc/bfd.texinfo: Rename to ... * doc/bfd.texi: ... this. * Makefile.in: Re-generate. * aclocal.m4: Re-generate. * config.in: Re-generate. * configure: Re-generate. * doc/Makefile.in: Re-generate. binutils/ChangeLog: * configure.ac: Remove AC_PREREQ. * doc/Makefile.am (AUTOMAKE_OPTIONS): Remove cygnus, add info-in-builddir no-texinfo.tex. * Makefile.in: Re-generate. * aclocal.m4: Re-generate. * config.in: Re-generate. * configure: Re-generate. * doc/Makefile.in: Re-generate. config/ChangeLog: * override.m4 (_GCC_AUTOCONF_VERSION): Bump from 2.64 to 2.69. etc/ChangeLog: * configure.in: Remove AC_PREREQ. * configure: Re-generate. gas/ChangeLog: * Makefile.am (AUTOMAKE_OPTIONS): Remove 1.11, add subdir-objects. (TARG_CPU_O, OBJ_FORMAT_O, ATOF_TARG_O): Add config/ prefix. * configure.ac (TARG_CPU_O, OBJ_FORMAT_O, ATOF_TARG_O, emfiles, extra_objects): Add config/ prefix. * doc/as.texinfo: Rename to... * doc/as.texi: ... this. * doc/Makefile.am: Rename as.texinfo to as.texi throughout. Remove DISTCLEANFILES hack. (AUTOMAKE_OPTIONS): Remove 1.8, cygnus, add no-texinfo.tex and info-in-builddir. * Makefile.in: Re-generate. * aclocal.m4: Re-generate. * config.in: Re-generate. * configure: Re-generate. * doc/Makefile.in: Re-generate. gdb/ChangeLog: * common/common-defs.h (PACKAGE_NAME, PACKAGE_VERSION, PACKAGE_STRING, PACKAGE_TARNAME): Undefine. * configure.ac: Remove AC_PREREQ, add missing quoting. * gnulib/configure.ac: Modernize usage of AC_INIT/AM_INIT_AUTOMAKE. Remove AC_PREREQ. * gnulib/update-gnulib.sh (AUTOCONF_VERSION): Bump to 2.69. (AUTOMAKE_VERSION): Bump to 1.15.1. * configure: Re-generate. * config.in: Re-generate. * aclocal.m4: Re-generate. * gnulib/aclocal.m4: Re-generate. * gnulib/config.in: Re-generate. * gnulib/configure: Re-generate. * gnulib/import/Makefile.in: Re-generate. gdb/gdbserver/ChangeLog: * configure.ac: Remove AC_PREREQ, add missing quoting. * configure: Re-generate. * config.in: Re-generate. * aclocal.m4: Re-generate. gdb/testsuite/ChangeLog: * configure.ac: Remove AC_PREREQ. * configure: Re-generate. gold/ChangeLog: * configure.ac: Remove AC_PREREQ, add missing quoting and usage of AC_LANG_SOURCE. * Makefile.in: Re-generate. * aclocal.m4: Re-generate. * configure: Re-generate. * testsuite/Makefile.in: Re-generate. gprof/ChangeLog: * configure.ac: Remove AC_PREREQ. * Makefile.am: Remove DISTCLEANFILES hack. (AUTOMAKE_OPTIONS): Remove 1.11, add info-in-builddir. * Makefile.in: Re-generate. * aclocal.m4: Re-generate. * configure: Re-generate. * gconfig.in: Re-generate. intl/ChangeLog: * configure.ac: Add AC_USE_SYSTEM_EXTENSIONS, remove AC_PREREQ. * configure: Re-generate. * config.h.in: Re-generate. * aclocal.m4: Re-generate. ld/ChangeLog: * configure.ac: Remove AC_PREREQ. * Makefile.am: Remove DISTCLEANFILES hack, rename ld.texinfo to ld.texi, ldint.texinfo to ldint.texi throughout. (AUTOMAKE_OPTIONS): Add info-in-builddir. * README: Rename ld.texinfo to ld.texi, ldint.texinfo to ldint.texi throughout. * gen-doc.texi: Likewise. * h8-doc.texi: Likewise. * ld.texinfo: Rename to ... * ld.texi: ... this. * ldint.texinfo: Rename to ... * ldint.texi: ... this. * Makefile.in: Re-generate. * aclocal.m4: Re-generate. * config.in: Re-generate. * configure: Re-generate. libdecnumber/ChangeLog: * configure.ac: Remove AC_PREREQ. * configure: Re-generate. * aclocal.m4. libiberty/ChangeLog: * configure.ac: Remove AC_PREREQ. * configure: Re-generate. * config.in: Re-generate. opcodes/ChangeLog: * Makefile.am (AUTOMAKE_OPTIONS): Remove 1.11. * configure.ac: Remove AC_PREREQ. * Makefile.in: Re-generate. * aclocal.m4: Re-generate. * configure: Re-generate. readline/ChangeLog.gdb: * configure: Re-generate. * examples/rlfe/configure: Re-generate. sim/ChangeLog: * All configure.ac: Remove AC_PREREQ. * All configure: Re-generate. zlib/ChangeLog.bin-gdb: * configure.ac: Modernize AC_INIT call, remove AC_PREREQ. * Makefile.am (AUTOMAKE_OPTIONS): Remove 1.8, cygnus, add foreign. * Makefile.in: Re-generate. * aclocal.m4: Re-generate. * configure: Re-generate.
2018-01-30Per-inferior target_terminal state, fix PR gdb/13211, morePedro Alves1-0/+3
In my multi-target branch I ran into problems with GDB's terminal handling that exist in master as well, with multi-inferior debugging. This patch adds a testcase for said problems (gdb.multi/multi-term-settings.exp), fixes the problems, fixes PR gdb/13211 as well (and adds a testcase for that too, gdb.base/interrupt-daemon.exp). The basis of the problem I ran into is the following. Consider a scenario where you have: - inferior 1 - started with "attach", process is running on some other terminal. - inferior 2 - started with "run", process is sharing gdb's terminal. In this scenario, when you stop/resume both inferiors, you want GDB to save/restore the terminal settings of inferior 2, the one that is sharing GDB's terminal. I.e., you want inferior 2 to "own" the terminal (in target_terminal::is_ours/target_terminal::is_inferior sense). Unfortunately, that's not what you get currently. Because GDB doesn't know whether an attached inferior is actually sharing GDB's terminal, it tries to save/restore its settings anyway, ignoring errors. In this case, this is pointless, because inferior 1 is running on a different terminal, but GDB doesn't know better. And then, because it is only possible to have the terminal settings of a single inferior be in effect at a time, or make one inferior/pgrp be the terminal's foreground pgrp (aka, only one inferior can "own" the terminal, ignoring fork children here), if GDB happens to try to restore the terminal settings of inferior 1 first, then GDB never restores the terminal settings of inferior 2. This patch fixes that and a few things more along the way: - Moves enum target_terminal::terminal_state out of the target_terminal class (it's currently private) and makes it a scoped enum so that it can be easily used elsewhere. - Replaces the inflow.c:terminal_is_ours boolean with a target_terminal_state variable. This allows distinguishing is_ours and is_ours_for_output states. This allows finally making child_terminal_ours_1 do something with its "output_only" parameter. - Makes each inferior have its own copy of the is_ours/is_ours_for_output/is_inferior state. - Adds a way for GDB to tell whether the inferior is sharing GDB's terminal. Works best on Linux and Solaris; the fallback works just as well as currently. - With that, we can remove the inf->attach_flag tests from child_terminal_inferior/child_terminal_ours. - Currently target_ops.to_ours is responsible for both saving the current inferior's terminal state, and restoring gdb's state. Because each inferior has its own terminal state (possibly handled by different targets in a multi-target world, even), we need to split the inferior-saving part from the gdb-restoring part. The patch adds a new target_ops.to_save_inferior target method for that. - Adds a new target_terminal::save_inferior() function, so that sequences like: scoped_restore_terminal_state save_state; target_terminal::ours_for_output (); ... restore back inferiors that were target_terminal_state::is_inferior before back to is_inferior, and leaves inferiors that were is_ours alone. - Along the way, this adds a default implementation of target_pass_ctrlc to inflow.c (for inf-child.c), that handles passing the Ctrl-C to a process running on GDB's terminal or to some other process otherwise. - Similarly, adds a new target default implementation of target_interrupt, for the "interrupt" command. The current implementation of this hook in inf-ptrace.c kills the whole process group, but that's incorrect/undesirable because we may not be attached to all processes in the process group. And also, it's incorrect because inferior_process_group() doesn't really return the inferior's real process group id if the inferior is not a process group leader... This is the cause of PR gdb/13211 [1], which this patch fixes. While at it, that target method's "ptid" parameter is eliminated, because it's not really used. - A new test is included that exercises and fixes PR gdb/13211, and also fixes a GDB issue reported on stackoverflow that I ran into while working on this [2]. The problem is similar to PR gdb/13211, except that it also triggers with Ctrl-C. When debugging a daemon (i.e., a process that disconnects from the controlling terminal and is not a process group leader, then Ctrl-C doesn't work, you just can't interrupt the inferior at all, resulting in a hung debug session. The problem is that since the inferior is no longer associated with gdb's session / controlling terminal, then trying to put the inferior in the foreground fails. And so Ctrl-C never reaches the inferior directly. pass_signal is only used when the inferior is attached, but that is not the case here. This is fixed by the new child_pass_ctrlc. Without the fix, the new interrupt-daemon.exp testcase fails with timeout waiting for a SIGINT that never arrives. [1] PR gdb/13211 - Async / Process group and interrupt not working https://sourceware.org/bugzilla/show_bug.cgi?id=13211 [2] GDB not reacting Ctrl-C when after fork() and setsid() https://stackoverflow.com/questions/46101292/gdb-not-reacting-ctrl-c-when-after-fork-and-setsid Note this patch does _not_ fix: - PR gdb/14559 - The 'interrupt' command does not work if sigwait is in use https://sourceware.org/bugzilla/show_bug.cgi?id=14559 - PR gdb/9425 - When using "sigwait" GDB doesn't trap SIGINT. Ctrl+C terminates program when should break gdb. https://sourceware.org/bugzilla/show_bug.cgi?id=9425 The only way to fix that that I know of (without changing the kernel) is to make GDB put inferiors in a separate session (create a pseudo-tty master/slave pair, make the inferior run with the slave as its terminal, and have gdb pump output/input on the master end). gdb/ChangeLog: 2018-01-30 Pedro Alves <palves@redhat.com> PR gdb/13211 * config.in, configure: Regenerate. * configure.ac: Check for getpgid. * go32-nat.c (go32_pass_ctrlc): New. (go32_target): Install it. * inf-child.c (inf_child_target): Install child_terminal_save_inferior, child_pass_ctrlc and child_interrupt. * inf-ptrace.c (inf_ptrace_interrupt): Delete. (inf_ptrace_target): No longer install it. * infcmd.c (interrupt_target_1): Adjust. * inferior.h (child_terminal_save_inferior, child_pass_ctrlc) (child_interrupt): Declare. (inferior::terminal_state): New. * inflow.c (struct terminal_info): Update comments. (inferior_process_group): Delete. (terminal_is_ours): Delete. (gdb_tty_state): New. (child_terminal_init): Adjust. (is_gdb_terminal, sharing_input_terminal_1) (sharing_input_terminal): New functions. (child_terminal_inferior): Adjust. Use sharing_input_terminal. Set the process's actual process group in the foreground if possible. Handle is_ours_for_output/is_ours distinction. Don't mark terminal as the inferior's if not sharing GDB's terminal. Don't check attach_flag. (child_terminal_ours_for_output, child_terminal_ours): Adjust to pass down a target_terminal_state. (child_terminal_save_inferior): New, factored out from ... (child_terminal_ours_1): ... this. Handle target_terminal_state::is_ours_for_output. (child_interrupt, child_pass_ctrlc): New. (inflow_inferior_exit): Clear the inferior's terminal_state. (copy_terminal_info): Copy the inferior's terminal state. (_initialize_inflow): Remove reference to terminal_is_ours. * inflow.h (inferior_process_group): Delete. * nto-procfs.c (nto_handle_sigint, procfs_interrupt): Adjust. * procfs.c (procfs_target): Don't install procfs_interrupt. (procfs_interrupt): Delete. * remote.c (remote_serial_quit_handler): Adjust. (remote_interrupt): Remove ptid parameter. Adjust. * target-delegates.c: Regenerate. * target.c: Include "terminal.h". (target_terminal::terminal_state): Rename to ... (target_terminal::m_terminal_state): ... this. (target_terminal::init): Adjust. (target_terminal::inferior): Adjust to per-inferior terminal_state. (target_terminal::restore_inferior, target_terminal_is_ours_kind): New. (target_terminal::ours, target_terminal::ours_for_output): Use target_terminal_is_ours_kind. (target_interrupt): Remove ptid parameter. Adjust. (default_target_pass_ctrlc): Adjust. * target.h (target_ops::to_terminal_save_inferior): New field. (target_ops::to_interrupt): Remove ptid_t parameter. (target_interrupt): Remove ptid_t parameter. Update comment. (target_pass_ctrlc): Update comment. * target/target.h (target_terminal_state): New scoped enum, factored out of ... (target_terminal::terminal_state): ... here. (target_terminal::inferior): Update comments. (target_terminal::restore_inferior): New. (target_terminal::is_inferior, target_terminal::is_ours) (target_terminal::is_ours_for_output): Adjust. (target_terminal::scoped_restore_terminal_state): Adjust to rename, and call restore_inferior() instead of inferior(). (target_terminal::scoped_restore_terminal_state::m_state): Change type. (target_terminal::terminal_state): Rename to ... (target_terminal::m_terminal_state): ... this and change type. gdb/gdbserver/ChangeLog: 2018-01-30 Pedro Alves <palves@redhat.com> PR gdb/13211 * target.c (target_terminal::terminal_state): Rename to ... (target_terminal::m_terminal_state): ... this. gdb/testsuite/ChangeLog: 2018-01-30 Pedro Alves <palves@redhat.com> PR gdb/13211 * gdb.base/interrupt-daemon.c: New. * gdb.base/interrupt-daemon.exp: New. * gdb.multi/multi-term-settings.c: New. * gdb.multi/multi-term-settings.exp: New.
2018-01-09Support 'info proc' for native FreeBSD processes.John Baldwin1-0/+3
- Command line arguments are fetched via the kern.proc.args.<pid> sysctl. - The 'cwd' and 'exe' values are obtained from the per-process file descriptor table returned by kinfo_getfile() from libutil. - 'mappings' is implemented by walking the array of VM map entries returned by kinfo_getvmmap() from libutil. - 'status' output is generated by outputting fields from the structure returned by the kern.proc.pid.<pid> sysctl. - 'stat' is aliased to 'status'. gdb/ChangeLog: * configure.ac: Check for kinfo_getfile in libutil. * configure: Regenerate. * config.in: Regenerate. * fbsd-nat.c: Include "fbsd-tdep.h". (fbsd_fetch_cmdline): New. (fbsd_fetch_kinfo_proc): Move earlier and change to return a bool rather than calling error. (fbsd_info_proc): New. (fbsd_thread_name): Report error if fbsd_fetch_kinfo_proc fails. (fbsd_wait): Report warning if fbsd_fetch_kinfo_proc fails. (fbsd_nat_add_target): Set "to_info_proc" to "fbsd_info_proc".
2017-11-30Remove ioctl-based procfs support on SolarisRainer Orth1-24/+0
This is the previously mentioned patch to get rid of unstructured/ioctl-based procfs support in procfs.c. Given that support for structured procfs was introduced in Solaris 2.6 back in 1997 and we're just removing support for Solaris < 10, there's no point in carrying that baggage (and tons of support for IRIX and OSF/1 as well) around any longer. Most of the patch should be straightforward (removing support for !NEW_PROC_API, non-Solaris OSes and pre-Solaris 10 quirks). Only a few points need explanations: * <sys/syscall.h> was already included unconditionally in most places, so there's no need to have guards in a few remaining ones. * configure.host already obsoletes i?86-*-sysv4.2, i?86-*-sysv5, so NEW_PROC_API detection for those in configure.ac can go. * I'm still including <sys/procfs.h> with #define _STRUCTURED_PROC 1. Theoretically, it would be better to include <procfs.h> on Solaris (which includes that define), but that breaks the build over <procfs.h> vs. gdb's "procfs.h", and doesn't exist on Linux. * I've regenerated syscall_table[] in proc-events.c with a small script from Solaris 10, 11.3, 11.4 <sys/syscall.h>, so there should be no traces of older Solaris versions and other OSes left. * prsysent_t and DYNAMIC_SYSCALLS was only used for AIX 5, but AIX doesn't use procfs.c any longer, so all related code can go. The patch was generated with diff -w so one can easier see changes without being distracted by simple reindentations. So far, it has only been compiled and smoke-tested on amd64-pc-solaris2.1[01], sparcv9-sun-solaris2.1[01], and x86_64-pc-linux-gnu. Certainly needs more testing (Solaris 11.3 vs. 11.4, 32-bit gdb, testsuite once I've figured out what's wrong on Solaris 10 etc.), but it's enough to get a first impression how much cleanup is possible here. * configure.ac Don't check for sys/fault.h, sys/syscall.h, sys/proc.h. (NEW_PROC_API): Remove. (prsysent_t, pr_sigset_t, pr_sigaction64_t, pr_siginfo64_t): Likewise. * common/common.m4 (GDB_AC_COMMON): Don't check for sys/syscall.h. * configure: Regenerate. * config.in: Regenerate. * gdbserver/configure: Regenerate. * gdbserver/config.in: Regenerate. * i386-sol2-nat.c (_initialize_amd64_sol2_nat): Remove NEW_PROC_API test. * sparc-sol2-nat.c (_initialize_sparc_sol2_nat): Likewise. * linux-btrace.c: Remove HAVE_SYS_SYSCALL_H test. * proc-api.c: Remove !NEW_PROC_API support. Remove HAVE_SYS_PROC_H and HAVE_SYS_USER_H tests. Remove tests for macros always defined on Solaris. * proc-events.c: Remove !NEW_PROC_API support. Remove Remove HAVE_SYS_SYSCALL_H, HAVE_SYS_PROC_H and HAVE_SYS_USER_H tests. (init_syscall_table): Remove non-Solaris syscalls. Remove tests for syscalls present on all Solaris versions. Add missing Solaris 10+ syscalls. (signal_table): Remove non-Solaris signals. Remove tests for signals present on all Solaris versions. (fault_table): Remove non-Solaris faults. Remove tests for faults present on all Solaris versions. * proc-flags.c: Remove !NEW_PROC_API support. (pr_flag_table): Remove non-Solaris and pre-Solaris 7 comments. Remove non-Solaris flags. * proc-why.c: Remove !NEW_PROC_API support. (pr_why_table): Remove meaningless comments. Remove tests for reasons present on all Solaris versions. Remove OSF/1 cases. (proc_prettyfprint_why): Likewise. * procfs.c: Remove !NEW_PROC_API and DYNAMIC_SYSCALLS support. Remove HAVE_SYS_FAULT_H and HAVE_SYS_SYSCALL_H tests. Remove WA_READ test, IRIX watchpoint support. (gdb_sigset_t, gdb_sigaction_t, gdb_siginfo_t): Replace by base types. Change users. (gdb_praddset, gdb_prdelset, gdb_premptysysset, gdb_praddsysset) (gdb_prdelset, gdb_pr_issyssetmember): Replace by base macros. Change callers. Remove CTL_PROC_NAME_FMT tests. (gdb_prstatus_t, gdb_lwpstatus_t): Replace by base types. Change users. (sysset_t_size): Remove. Use sizeof (sysset_t) in callers. Remove PROCFS_DONT_PIOCSSIG_CURSIG support. (proc_modify_flag): Replace GDBRESET by PCUNSET. Remove PR_ASYNC, PR_KLC tests. (proc_unset_inherit_on_fork): Remove PR_ASYNC test. (proc_parent_pid): Remove PCWATCH etc. tests. (proc_set_watchpoint): Remove !PCWATCH && !PIOCSWATCH support. Remove PCAGENT test. (proc_get_nthreads) [PIOCNTHR && PIOCTLIST]: Remove. Remove SYS_lwpcreate || SYS_lwp_create test. (proc_get_current_thread): Likewise. [PIOCNTHR && PIOCTLIST]: Remove. [PIOCLSTATUS]: Remove. (procfs_debug_inferior): Remove non-Solaris cases, conditionals. [PRFS_STOPEXEC]: Remove. (syscall_is_lwp_exit): Remove non-Solaris cases, conditionals. (syscall_is_exit): Likewise. (syscall_is_exec): Likewise. (syscall_is_lwp_create): Likewise. Remove SYS_syssgi support. (procfs_wait): Remove PR_ASYNC, !PIOCSSPCACT tests. [SYS_syssgi]: Remove. Remove non-Solaris cases, conditionals. (unconditionally_kill_inferior) [PROCFS_NEED_PIOCSSIG_FOR_KILL]: Remove. (procfs_init_inferior) [SYS_syssgi]: Remove. (procfs_set_exec_trap) [PRFS_STOPEXEC]: Remove. (procfs_inferior_created) [SYS_syssgi]: Remove. (procfs_set_watchpoint): Remove !AIX5 test. (procfs_stopped_by_watchpoint): Remove FLTWATCH test, FLTKWATCH case. (mappingflags) [MA_PHYS]: Remove. (info_mappings_callback): Remove PCAGENT test. Remove PIOCOPENLWP || PCAGENT test.
2017-11-22Target FP: Make use of MPFR if availableUlrich Weigand1-0/+3
This second patch introduces mfpr_float_ops, an new implementation of target_float_ops. This implements precise emulation of target floating-point formats using the MPFR library. This is then used to perform operations on types that do not match any host type. Note that use of MPFR is still not required. The patch adds a configure option --with-mpfr similar to --with-expat. If use of MPFR is disabled via the option or MPFR is not available, code will fall back to current behavior. This means that operations on types that do not match any host type will be implemented on the host long double type instead. A new test case verifies that we can correctly print the largest __float128 value now. gdb/ChangeLog: 2017-11-22 Ulrich Weigand <uweigand@de.ibm.com> * NEWS: Document use of GNU MPFR. * README: Likewise. * Makefile.in (LIBMPFR): Add define. (CLIBS): Add $(LIBMPFR). * configure.ac: Add --with-mpfr configure option. * configure: Regenerate. * config.in: Regenerate. * target-float.c [HAVE_LIBMPFR]: Include <mpfr.h>. (class mpfr_float_ops): New type. (mpfr_float_ops::from_target): Two new overloaded functions. (mpfr_float_ops::to_target): Likewise. (mpfr_float_ops::to_string): New function. (mpfr_float_ops::from_string): Likewise. (mpfr_float_ops::to_longest): Likewise. (mpfr_float_ops::from_longest): Likewise. (mpfr_float_ops::from_ulongest): Likewise. (mpfr_float_ops::to_host_double): Likewise. (mpfr_float_ops::from_host_double): Likewise. (mpfr_float_ops::convert): Likewise. (mpfr_float_ops::binop): Likewise. (mpfr_float_ops::compare): Likewise. (get_target_float_ops): Use mpfr_float_ops if available. gdb/doc/ChangeLog: 2017-11-22 Ulrich Weigand <uweigand@de.ibm.com> * gdb.texinfo (Requirements): Document use of GNU MPFR. gdb/testsuite/ChangeLog: 2017-11-22 Ulrich Weigand <uweigand@de.ibm.com> * gdb.base/float128.c (large128): New variable. * gdb.base/float128.exp: Add test to print largest __float128 value.
2017-11-06Don't check termio.h and sgtty.h in common/common.m4 eitherPedro Alves1-6/+0
common/common.m4 still had checks for termio.h/sgtty.h that are stale now. Remove them. gdb/ChangeLog: 2017-11-06 Pedro Alves <palves@redhat.com> * common/common.m4 (GDB_AC_COMMON): No longer check termio.h nor sgtty.h. * config.in, configure: Regenerate. gdb/gdbserver/ChangeLog: 2017-11-06 Pedro Alves <palves@redhat.com> * config.in, configure: Regenerate.
2017-09-26Allow linking GDB with ncurseswMatthias Klose1-0/+3
Triggered by https://launchpad.net/bugs/1275210, to be able to cope with UTF-8 characters in gdbtui. Reference: https://sourceware.org/ml/gdb-patches/2017-09/msg00356.html gdb/ChangeLog: 2017-09-26 Matthias Klose <doko@ubuntu.com> * configure.ac: Search ncursesw before ncurses. Check ncursesw/ncurses.h before ncurses/ncurses.h. * gdb_curses.h: Include <ncursesw/ncurses.h> * config.in, configure: Regenerate.
2017-09-26Remove support for Solaris < 10 (PR gdb/22185)Rainer Orth1-17/+0
Given that GCC has obsoleted/removed support for Solaris 9 in GCC 4.9/5 in 2013: https://gcc.gnu.org/gcc-4.9/changes.html https://gcc.gnu.org/ml/gcc-patches/2013-05/msg00728.html and the last gdb version that can be compiled with gcc 4.9 is 7.12.1 only when configured with --disable-build-with-cxx, it's time to obsolete/remove support for Solaris < 10. This patch does this, simplifying configure.nat along the way (only a single sol2 configuration with variants for i386 and sparc). Some configure checks for older Solaris versions can go, too, and the check for libthread_db.so.1 removed: * Since Solaris 10, dlopen has moved to libc and libdl.so is just a filter on ld.so.1, so no need to check. * $RDYNAMIC is already handled above (and is a no-op with Solaris ld anyway). Both proc-service.c and sol-thread.c lose support for (Solaris-only) PROC_SERVICE_IS_OLD. The attached revised patch has been tested on sparcv9-sun-solaris2.10, sparcv9-sun-solaris2.11.4, amd64-pc-solaris2.10, amd64-pc-solaris2.11.4, and x86_64-pc-linux-gnu. I've also started an i386-pc-solaris2.9 build to check that it really stops as expected. PR gdb/22185 * configure.host <*-*-solaris2.[01], *-*-solaris2.[2-9]*>: Mark as obsolete. Use gdb_host sol2 for i[34567]86-*-solaris2*, x86_64-*-solaris2*. Remove i386sol2 support. * configure.nat <i386sol2>: Remove. <sol2-64>: Fold into ... <sol2>: ... this. Move common settings to default section. Add sol-thread.o. * configure.tgt <i[34567]86-*-solaris2.1[0-9]*, x86_64-*-solaris2.1[0-9]*>: Rename to ... <i[34567]86-*-solaris2*, x86_64-*-solaris2*>: ... this. <i[34567]86-*-solaris*>: Remove. <sparc-*-solaris2.[0-6], sparc-*-solaris2.[0-6].*>: Remove. * configure.ac: Remove wctype in libw check. (_MSE_INT_H): Don't define on Solaris 7-9. <solaris*>: Remove libthread_db.so.1 check. * configure: Regenerate. * config.in: Regenerate. * proc-service.c: Remove PROC_SERVICE_IS_OLD handling. (gdb_ps_prochandle_t, gdb_ps_read_buf_t, gdb_ps_write_buf_t) (gdb_ps_size_t): Remove. Use base types in users. * sol-thread.c: Likewise, also for gdb_ps_addr_t. * NEWS (Changes since GDB 8.0): Document Solaris 2.0-9 removal.
2017-05-31config, btrace: check for pt_insn_event in libiptMarkus Metzger1-0/+9
Version 2 of libipt adds an event system to instruction flow decoders and deprecates indicating events via flags in struct pt_insn. Add configuration checks to determine which version we have. gdb/ * configure.ac: Check for pt_insn_event, struct pt_insn.enabled, and struct pt_insn.resynced. * configure: Regenerated. * config.in: Regenerated.
2016-10-31Remove IRIX 5 <sys/proc.h> _KMEMUSER workaroundMaciej W. Rozycki1-4/+0
Complement commit 3831839c089c ("Delete IRIX support") and remove the IRIX 5 <sys/proc.h> _KMEMUSER workaround from the `configure' script, as IRIX is no longer a supported host configuration. gdb/ * configure.ac <mips-sgi-irix5*>: Remove <sys/proc.h> _KMEMUSER workaround. * configure: Regenerate. * config.in: Regenerate.
2016-10-28gdb: Require C++11Pedro Alves1-0/+3
Use AX_CXX_COMPILE_STDCXX to detect if the compiler supports C++11, and if -std=xxx switches are necessary to enable C++11. We need to tweak AX_CXX_COMPILE_STDCXX a bit though. Pristine upstream AX_CXX_COMPILE_STDCXX appends -std=gnu++11 to CXX directly. That doesn't work for us, because the top level Makefile passes CXX down to subdirs, and that overrides whatever gdb/Makefile may set CXX to. The result would be that a make invocation from the build/gdb/ directory would use "g++ -std=gnu++11" as expected, while a make invocation at the top level would not. So instead of having AX_CXX_COMPILE_STDCXX set CXX directly, tweak it to AC_SUBST a separate variable -- CXX_DIALECT -- and use '$(CXX) (CXX_DIALECT)' to compile/link. Confirmed that this enables C++11 starting with gcc 4.8, the first gcc release with full C++11 support. Also confirmed that configure errors out gracefully with older GCC releases: checking whether /opt/gcc-4.7/bin/g++ supports C++11 features by default... no checking whether /opt/gcc-4.7/bin/g++ supports C++11 features with -std=gnu++11... no checking whether /opt/gcc-4.7/bin/g++ supports C++11 features with -std=gnu++0x... no checking whether /opt/gcc-4.7/bin/g++ supports C++11 features with -std=c++11... no checking whether /opt/gcc-4.7/bin/g++ supports C++11 features with -std=c++0x... no checking whether /opt/gcc-4.7/bin/g++ supports C++11 features with +std=c++11... no checking whether /opt/gcc-4.7/bin/g++ supports C++11 features with -h std=c++11... no configure: error: *** A compiler with support for C++11 language features is required. Makefile:9451: recipe for target 'configure-gdb' failed make[1]: *** [configure-gdb] Error 1 make[1]: Leaving directory '/home/pedro/brno/pedro/gdb/mygit/cxx-convertion/build-gcc-4.7' If we need to revert back to making C++11 optional, all that's necessary is to change the "mandatory" to "optional" in configure.ac and regenerate configure (both gdb and gdbserver). gdb/ChangeLog: 2016-10-28 Pedro Alves <palves@redhat.com> * Makefile.in (CXX_DIALECT): Get from configure. (COMPILE.pre, CC_LD): Append $(CXX_DIALECT). (FLAGS_TO_PASS): Pass CXX_DIALECT. * acinclude.m4: Include ax_cxx_compile_stdcxx.m4. * ax_cxx_compile_stdcxx.m4: Add FSF copyright header. Set and AC_SUBST CXX_DIALECT instead of changing CXX/CXXCPP. * configure.ac: Call AX_CXX_COMPILE_STDCXX. * config.in: Regenerate. * configure: Regenerate. gdb/gdbserver/ChangeLog: 2016-10-28 Pedro Alves <palves@redhat.com> * Makefile.in (CXX_DIALECT): Get from configure. (COMPILE.pre, CC_LD): Append $(CXX_DIALECT). * acinclude.m4: Include ../ax_cxx_compile_stdcxx.m4. * configure.ac: Call AX_CXX_COMPILE_STDCXX. * config.in: Regenerate. * configure: Regenerate.