Add the --enable-threading configure option so multithreading can be disabled
at configure time. This is useful for statically-linked builds of
GDB/GDBserver, since the thread library doesn't play well with that setup.
If you try to run a statically-linked GDB built with threading, it will crash
when setting up the number of worker threads.
This new option is also convenient when debugging GDB in a system with lots of
threads, where the thread discovery code in GDB will emit too many messages,
like so:
[New Thread 0xfffff74d3a50 (LWP 2625599)]
If you have X threads, that message will be repeated X times.
The default for --enable-threading is "yes".
The variable names used to restore CFLAGS and LDFLAGS here don't quite
match the names used above, resulting in losing the original CFLAGS and
LDFLAGS. Fix that.
Change-Id: I9cc2c3b48b1dc30c31a7143563c893fd6f426a0a
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.
When building gdb with g++ 4.8.5, I ran into:
...
ld: source-cache.o: in function `source_cache::ensure(symtab*)':
source-cache.c:207: undefined reference to \
srchilite::SourceHighlight::SourceHighlight(std::string const&)
...
[ I configured gdb without explicit settings related to source-highlight, so
we're excercising the enable_source_highlight=auto scenario. ]
The problem is that:
- the source-highlight library is build with system compiler
g++ 7.5.0 which uses the new libstdc++ library abi (see
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html )
- gdb is build using g++ 4.8.5 which uses the old abi.
[ There's a compatibility macro _GLIBCXX_USE_CXX11_ABI, but that doesn't work
for this case. Instead, it enables the opposite case where the
source-highlight library is build with g++ 4.8.5 and gdb is build with
g++ 7.5.0. ]
Fix this by checking whether the source-highlight library is usable during
configuration.
In the enable_source_highlight=auto scenario, this allows the build to skip
the unusable library and finish successfully.
In the enable_source_highlight=yes scenario, this allows the build to error
out earlier.
Tested on x86_64-linux.
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.
The format_pieces selftest currently fails on Windows hosts.
The selftest doesn't handle the "%ll" -> "%I64" rewrite that the
formatter may perform, but also gdbsupport was missing a configure
check for PRINTF_HAS_LONG_LONG. This patch fixes both issues.
Say we use a gcc version that (while supporting c++11) does not support c++11
by default, and needs an -std setting to enable it.
If gdb would use the default AX_CXX_COMPILE_STDCXX from autoconf-archive, then
we'd have:
...
CXX="g++ -std=gnu++11"
...
That mechanism however has the following problem (quoting from commit
0bcda68539):
...
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.
...
Commit 0bcda68539 fixes this by using a custom AX_CXX_COMPILE_STDCXX which
does:
...
CXX=g++
CXX_DIALECT=-std=gnu++11
...
The problem reported in PR28318 is that using the custom instead of the
default AX_CXX_COMPILE_STDCXX makes the configure test for std::thread
support fail.
We could simply add $CXX_DIALECT to the test for std::thread support, but
that would have to be repeated for each added c++ support test.
Instead, fix this by doing:
...
CXX="g++ -std=gnu++11"
CXX_DIALECT=-std=gnu++11
...
This is somewhat awkward, since it results in -std=gnu++11 occuring twice in
some situations:
...
$ touch src/gdb/dwarf2/read.c
$ ( cd build/gdb; make V=1 dwarf2/read.o )
g++-4.8 -std=gnu++11 -x c++ -std=gnu++11 ...
...
However, both settings are needed:
- the switch in CXX for the std::thread tests (and other tests)
- the switch in CXX_DIALECT so it can be appended in Makefiles, to
counteract the fact that the top-level Makefile overrides CXX
The code added in gdb/ax_cxx_compile_stdcxx.m4 is copied from the default
AX_CXX_COMPILE_STDCXX from autoconf-archive.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28318
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}.
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.
Commit f99d1d3749 ("Remove gdb/testsuite/configure") removed
gdb/testsuite/configure, as anything gdb/testsuite/configure did could
be done by gdb/configure.
There is however one use case that popped up when this changed
propagated to downstream consumers, to run the testsuite on an already
built GDB. In the workflow of ROCm-GDB at AMD, a GDB package is built
in a CI job. This GDB package is then tested on different machines /
hardware configurations as part of other CI jobs. To achieve this,
those CI jobs only configure the testsuite directory and run "make
check" with an appropriate board file.
In light of this use case, the way I see it is that gdb/testsuite could
be considered its own project. It could be stored in a completely
different repo if we want to, it just happens to be stored inside gdb/.
Since the only downside of having gdb/testsuite/configure is that it
takes a few more seconds to run, but on the other hand it's quite useful
for some people, I propose re-adding it.
In a sense, this is revert of f99d1d3749, but it's not a direct
git-revert, as some things have changed since.
gdb/ChangeLog:
* configure.ac: Remove things that were moved from
testsuite/configure.ac.
* configure: Re-generate.
gdb/testsuite/ChangeLog:
* configure.ac: Restore.
* configure: Re-generate.
* aclocal.m4: Re-generate.
* Makefile.in (distclean): Add config.status.
(Makefile): Adjust paths.
(lib/pdtrace): Adjust paths.
(config.status): Add.
Change-Id: Ic38c79485e1835712d9c99649c9dfb59667254f1
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
These dirs don't use automake, so use AC_CONFIG_MACRO_DIRS to specify
../config as a search dir for m4 macros. This allows removal of a lot
of hand-written m4_include's from acinclude.m4 files, and simplifies
use of `aclocal` or `autoreconf` as manual -I is not needed.
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.
Shahab Vahedi pointed out that the patch to remove
gdb/testsuite/configure regressed the site.exp creation a bit -- it
left an unresolved configure substitution. Andrew Burgess pointed out
that the patch removed the call to ACX_NONCANONICAL_TARGET, which
caused this problem.
This patch adds ACX_NONCANONICAL_TARGET to gdb's configure, and fixes
the bug.
gdb/ChangeLog
2021-06-05 Tom Tromey <tromey@adacore.com>
* configure: Rebuild.
* configure.ac: Add ACX_NONCANONICAL_TARGET.
The old testsuite configure did not use AS_HELP_STRING, and it had a
typo in the help for --enable-shared. This patch fixes these
problems.
gdb/ChangeLog
2021-06-01 Tom Tromey <tromey@adacore.com>
* configure: Rebuild.
* configure.ac: Use AS_HELP_STRING for enable-shared. Fix typo.
I didn't see a strong reason to have a separate configure script in
gdb/testsuite, so this patch removes it. The few relevant configury
bits are moved into gdb's configure script. Some of the old
testsuite/configure script (e.g., the header check) is dead code.
This also adds a Makefile rule to rebuild lib/pdtrace. This was
missing from the old code.
'read1' is now a dependency of check-read1, rather than extra code at
configure time.
Finally, the old "ENABLE_LIBCTF" subst in gdb/configure was not used;
nor was the variable defined, so this was always empty. However, the
lower-case variant was used by the testsuite, so this patch renames
the subst.
gdb/ChangeLog
2021-06-01 Tom Tromey <tromey@adacore.com>
* configure.ac: Copy some code from testsuite/configure.ac.
(enable_libctf): Subst this, not ENABLE_LIBCTF.
* configure: Rebuild.
gdb/testsuite/ChangeLog
2021-06-01 Tom Tromey <tromey@adacore.com>
* aclocal.m4, configure.ac, configure: Remove.
* Makefile.in (EXTRA_RULES): Remove.
($(abs_builddir)/site.exp site.exp): Don't depend on
config.status.
(distclean maintainer-clean realclean, Makefile): Update.
(config.status): Remove target.
(lib/pdtrace): New target.
(all): Don't depend on EXTRA_RULES.
(check-read1): Depend on read1.so, expect-read1.
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.
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.
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'.
This commit adds the ability for bare metal RISC-V target to generate
core files from within GDB.
The intended use case is that a user will connect to a remote bare
metal target, debug up to some error condition, then generate a core
file in the normal way using:
(gdb) generate-core-file
This core file can then be used to revisit the state of the remote
target without having to reconnect to the remote target.
The core file creation code is split between two new files. In
elf-none-tdep.c is code for any architecture with the none
ABI (i.e. bare metal) when the BFD library is built with ELF support.
In riscv-none-tdep.c are the RISC-V specific parts. This is where the
regset and regcache_map_entry structures are defined that control how
registers are laid out in the core file. As this file could (in
theory at least) be used for a non-ELF bare metal RISC-V target, the
calls into elf-none-tdep.c are guarded with '#ifdef HAVE_ELF'.
Currently for RISC-V only the x-regs and f-regs (if present) are
written out. In future commits I plan to add support for writing out
the RISC-V CSRs.
The core dump format is based around generating an ELF containing
sections for the writable regions of memory that a user could be
using. Which regions are dumped rely on GDB's existing common core
dumping code, GDB will attempt to figure out the stack and heap as
well as copying out writable data sections as identified by the
original ELF.
Register information is added to the core dump using notes, just as it
is for Linux of FreeBSD core dumps. The note types used consist of
the 3 basic types you would expect in a OS based core dump,
NT_PRPSINFO, NT_PRSTATUS, NT_FPREGSET.
The layout of these notes differs slightly (due to field sizes)
between RV32 and RV64. Below I describe the data layout for each
note. In all cases, all padding fields should be set to zero.
Note NT_PRPSINFO is optional. Its data layout is:
struct prpsinfo32_t /* For RV32. */
{
uint8_t padding[32];
char fname[16];
char psargs[80];
}
struct prpsinfo64_t /* For RV64. */
{
uint8_t padding[40];
char fname[16];
char psargs[80];
}
Field 'fname' - null terminated string consisting of the basename of
(up to the fist 15 characters of) the executable. Any additional
space should be set to zero. If there's no executable name then
this field can be set to all zero.
Field 'psargs' - a null terminated string up to 80 characters in
length. Any additional space should be filled with zero. This
field contains the full executable path and any arguments passed
to the executable. If there's nothing sensible to write in this
field then fill it with zero.
Note NT_PRSTATUS is required, its data layout is:
struct prstatus32_t /* For RV32. */
{
uint8_t padding_1[12];
uint16_t sig;
uint8_t padding_2[10];
uint32_t thread_id;
uint8_t padding_3[44];
uint32_t x_regs[32];
uint8_t padding_4[4];
}
struct prstatus64_t /* For RV64. */
{
uint8_t padding_1[12];
uint16_t sig;
uint8_t padding_2[18];
uint32_t thread_id;
uint8_t padding_3[76];
uint64_t x_regs[32];
uint8_t padding_4[4];
}
Field 'sig' - the signal that stopped this thread. It's implementation
defined what this field actually means. Within GDB this will be
the signal number that the remote target reports as the stop
reason for this thread.
Field 'thread_is' - the thread id for this thread. It's implementation
defined what this field actually means. Within GDB this will be
thread thread-id that is assigned to each remote thread.
Field 'x_regs' - at index 0 we store the program counter, and at
indices 1 to 31 we store x-registers 1 to 31. x-register 0 is not
stored, its value is always zero anyway.
Note NT_FPREGSET is optional, its data layout is:
fpregset32_t /* For targets with 'F' extension. */
{
uint32_t f_regs[32];
uint32_t fcsr;
}
fpregset64_t /* For targets with 'D' extension . */
{
uint64_t f_regs[32];
uint32_t fcsr;
}
Field 'f_regs' - stores f-registers 0 to 31.
Field 'fcsr' - stores the fcsr CSR register, and is always 4-bytes.
The rules for ordering the notes is the same as for Linux. The
NT_PRSTATUS note must come before any other notes about additional
register sets. And for multi-threaded targets all registers for a
single thread should be grouped together. This is because only
NT_PRSTATUS includes a thread-id, all additional register notes after
a NT_PRSTATUS are assumed to belong to the same thread until a
different NT_PRSTATUS is seen.
gdb/ChangeLog:
* Makefile.in (ALL_TARGET_OBS): Add riscv-none-tdep.o.
(ALLDEPFILES): Add riscv-none-tdep.c.
* configure: Regenerate.
* configure.ac (CONFIG_OBS): Add elf-none-tdep.o when BFD has ELF
support.
* configure.tgt (riscv*-*-*): Include riscv-none-tdep.c.
* elf-none-tdep.c: New file.
* elf-none-tdep.h: New file.
* riscv-none-tdep.c: New file.
While reviewing the Linux and FreeBSD core dumping code within GDB for
another patch series, I noticed that the code that collects the
registers for each thread and writes these into ELF note format is
basically identical between Linux and FreeBSD.
This commit merges this code and moves it into a new file gcore-elf.c.
The function find_signalled_thread is moved from linux-tdep.c to
gcore.c despite not being shared. A later commit will make use of
this function.
I did merge, and then revert a previous version of this patch (commit
82a1fd3a49 for the original patch and 03642b7189 for the revert).
The problem with the original patch is that it introduced a
unconditional dependency between GDB and some ELF specific functions
in the BFD library, e.g. elfcore_write_prstatus and
elfcore_write_register_note. It was pointed out in this mailing list
post:
https://sourceware.org/pipermail/gdb-patches/2021-February/175750.html
that this change was breaking any build of GDB for non-ELF targets.
To confirm this breakage, and to test this new version of GDB I
configured and built for the target x86_64-apple-darwin20.3.0.
Where the previous version of this patch placed all of the common code
into gcore.c, which is included in all builds of GDB, this new patch
only places non-ELF specific generic code (i.e. find_signalled_thread)
into gcore.c, the ELF specific code is put into the new gcore-elf.c
file, which is only included in GDB if BFD has ELF support.
The contents of gcore-elf.c are referenced unconditionally from
linux-tdep.c and fbsd-tdep.c, this is fine, we previously always
assumed that these two targets required ELF support, and we continue
to make that assumption after this patch; nothing has changed there.
With my previous version of this patch the darwin target mentioned
above failed to build, but with the new version, the target builds
fine.
There are a couple of minor changes to the FreeBSD target after this
commit, but I believe that these are changes for the better:
(1) For FreeBSD we always used to record the thread-id in the core
file by using ptid_t.lwp (). In contrast the Linux code did this:
/* For remote targets the LWP may not be available, so use the TID. */
long lwp = ptid.lwp ();
if (lwp == 0)
lwp = ptid.tid ();
Both target now do this:
/* The LWP is often not available for bare metal target, in which case
use the tid instead. */
if (ptid.lwp_p ())
lwp = ptid.lwp ();
else
lwp = ptid.tid ();
Which is equivalent for Linux, but is a change for FreeBSD. I think
that all this means is that in some cases where GDB might have
previously recorded a thread-id of 0 for each thread, we might now get
something more useful.
(2) When collecting the registers for Linux we collected into a zero
initialised buffer. By contrast on FreeBSD the buffer is left
uninitialised. In the new code the buffer is always zero initialised.
I suspect once the registers are copied into the buffer there's
probably no gaps left so this makes no difference, but if it does then
using zeros rather than random bits of GDB's memory is probably a good
thing.
Otherwise, there should be no other user visible changes after this
commit.
Tested this on x86-64/GNU-Linux and x86-64/FreeBSD-12.2 with no
regressions.
gdb/ChangeLog:
* Makefile.in (SFILES): Add gcore-elf.c.
(HFILES_NO_SRCDIR): Add gcore-elf.h
* configure: Regenerate.
* configure.ac: Add gcore-elf.o to CONFIG_OBS if we have ELF
support.
* fbsd-tdep.c: Add 'gcore-elf.h' include.
(struct fbsd_collect_regset_section_cb_data): Delete.
(fbsd_collect_regset_section_cb): Delete.
(fbsd_collect_thread_registers): Delete.
(struct fbsd_corefile_thread_data): Delete.
(fbsd_corefile_thread): Delete.
(fbsd_make_corefile_notes): Call
gcore_elf_build_thread_register_notes instead of the now deleted
FreeBSD code.
* gcore-elf.c: New file, the content was moved here from
linux-tdep.c, functions were renamed and given minor cleanup.
* gcore-elf.h: New file.
* gcore.c (gcore_find_signalled_thread): Moved here from
linux-tdep.c and given a new name. Minor cleanups.
* gcore.h (gcore_find_signalled_thread): Declare.
* linux-tdep.c: Add 'gcore.h' and 'gcore-elf.h' includes.
(struct linux_collect_regset_section_cb_data): Delete.
(linux_collect_regset_section_cb): Delete.
(linux_collect_thread_registers): Delete.
(linux_corefile_thread): Call
gcore_elf_build_thread_register_notes.
(find_signalled_thread): Delete.
(linux_make_corefile_notes): Call gcore_find_signalled_thread.
Avoid the error message when source-highlight is actually available.
2020-12-19 Bernd Edlinger <bernd.edlinger@hotmail.de>
* configure.ac: Move the static libs vs. source-highlight
error message to a better place.
* configure: Regenerate.
I am getting
I'm sorry, Dave, I can't do that. Symbol format `elf64-littleriscv' unknown.
errors after updating from GDB 8.3 to 10. Bisecting showed that since
commit 1ff6de0312 ("bfd, ld: add CTF section linking"), bfd.h depends
on strncmp() being present, so configuring with
-Werror=implicit-function-declaration results in the check for ELF
support in BFD failing:
.../gdb/gdb/../bfd/elf-bfd.h: In function 'bfd_section_is_ctf':
.../gdb/gdb/../bfd/elf-bfd.h:3086:10: error: implicit declaration of function 'strncmp' [-Werror=implicit-function-declaration]
return strncmp (name, ".ctf", 4) == 0 && (name[4] == 0 || name[4] == '.');
gdb/ChangeLog:
* acincludde.m4 (GDB_AC_CHECK_BFD): Include string.h in the test
program.
Change-Id: Iec5e21d454c2a544c44d65e23cfde552c424c18e
This commit modifies gdb's configure script to trigger an error
if we cannot find a usable libgmp.
For the record, making this a requirement was discussed in March 2018:
https://sourceware.org/pipermail/gdb-patches/2018-March/147373.html
gdb/ChangeLog:
* configure.ac: Generate an error if a usable GMP library
could not be found.
* configure: Regenerate.
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
In python 3, itertools is a builtin module, so whether or not the
python you link against is a shared or a static one, importing it
works.
Change the import test to use ctypes which is a dynamic module in both
python 2 and 3.
gdb/ChangeLog:
PR python/26832
* configure: Regenerate.
* configure.ac: Check for python modules ctypes instead of
itertools.
... with AC_LINK_IFELSE + AC_LANG_PROGRAM.
All changes in the generated configure file are insignificant whitespace
changes.
gdb/ChangeLog:
* configure: Re-generate.
* sanitize.m4: Replace AC_TRY_LINK with AC_LINK_IFELSE +
AC_LANG_PROGRAM.
Change-Id: I6fc4c39e10b28d2ade964e0d59a7f8ec0d3a272a
For some reason, autoupdate isn't able to grok ptrace.m4:
$ autoupdate ptrace.m4
/usr/bin/m4:/tmp/auYjuodw/input.m4:171: ERROR: end of file in string
autoupdate: /usr/bin/m4 failed with exit status: 1
Honestly, I'm unable to grok it either. This patch re-indents it in a
way that I think is easier to read. With this patch applied, autoupdate
becomes able to parse ptrace.m4, but I chose to keep this re-indent in a
patch of its own.
All the changes in generated configure files consist of insignificant
whitespace changes.
gdb/ChangeLog:
* configure: Re-generate.
gdbserver/ChangeLog:
* configure: Re-generate.
gdbsupport/ChangeLog:
* configure: Re-generate.
* ptrace.m4: Re-indent.
Change-Id: Ie2afab09fecc8b6d0cccccb47ac9756f3843881e
Run autoupdate on configure.ac and adjust the indentation of the result
for better readability. This removes a bunch of warnings when running
`autoreconf -vf -Wall`. The changes are:
* Replace AC_INIT with AC_INIT and no arguments plus
AC_CONFIG_SRCDIR.
* Replace AC_ERROR with AC_MSG_ERROR.
* Replace AC_TRY_LINK with AC_LINK_IFELSE.
* Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE.
* Replace AC_HELP_STRING with AS_HELP_STRING.
autoupdate erroneously tries to replace AC_C_LONG_DOUBLE in a comment,
which I reverted manually.
All the changes in the generated configure file are insignificant
whitespaces changes.
gdb/ChangeLog:
* configure.ac: Modernize.
* configure: Re-generate.
Change-Id: Ie3a1409c8032a36a6383da964286a46ece9b546e
`autoconf -Wall` notes that AM_PROG_CC_STDC is obsolete:
Fixes this autoconf warning:
configure.ac:40: warning: 'AM_PROG_CC_STDC': this macro is obsolete.
configure.ac:40: You should simply use the 'AC_PROG_CC' macro instead.
configure.ac:40: Also, your code should no longer depend upon 'am_cv_prog_cc_stdc',
configure.ac:40: but upon 'ac_cv_prog_cc_stdc'.
aclocal.m4:770: AM_PROG_CC_STDC is expanded from...
configure.ac:40: the top level
Since we build with a C++ compiler now, I don't think this is relevant.
If you look at the messages removed from gdbsupport/aclocal.m4, it says
that this functionality is now integrated in AC_PROG_CC, which we
already call. So it might not even make a difference.
We had a local version of AM_PROG_CC_STDC, in gdb/acinclude.m4 (only
used by gdb/configure.ac), remove it.
gdb/ChangeLog:
* acinclude.m4 (AM_PROG_CC_STDC): Remove.
* configure: Re-generate.
* configure.ac: Remove AM_PROG_CC_STDC.
gdbsupport/ChangeLog:
* aclocal.m4: Re-generate.
* configure: Re-generate.
* configure.ac: Remove AM_PROG_CC_STDC.
Change-Id: Ic824393598805d4f78cda9d119f8af46096e9c73
`autoreconf -Wall` notes that AC_CANONICAL_SYSTEM is obsolete:
configure.ac:36: warning: The macro `AC_CANONICAL_SYSTEM' is obsolete.
Replace it by AC_CANONICAL_BUILD, AC_CANONICAL_HOST and
AC_CANONICAL_TARGET in configure.ac files in gdb, gdbserver and
gdbsupport. All three macros may not be needed everywhere, but it is
hard to completely audit the configure files to see which are required,
so I think it's better (and that there's no downside) to just call all
three.
gdb/ChangeLog:
* configure.ac: Use AC_CANONICAL_{BUILD,HOST,TARGET} instead of
AC_CANONICAL_SYSTEM.
* configure: Re-generate.
gdbserver/ChangeLog:
* configure.ac: Use AC_CANONICAL_{BUILD,HOST,TARGET} instead of
AC_CANONICAL_SYSTEM.
* configure: Re-generate.
gdbsupport/ChangeLog:
* configure.ac: Use AC_CANONICAL_{BUILD,HOST,TARGET} instead of
AC_CANONICAL_SYSTEM.
* configure: Re-generate.
Change-Id: Ifd0e21f1e478634e768b5de1b8ee06a7f690d863
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.
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.
There is no need to check $pkg_cv_[]$1[]_LIBS works if package check
failed.
config/
PR binutils/26301
* pkg.m4 (PKG_CHECK_MODULES): Use AC_TRY_LINK only if
$pkg_failed = no.
binutils/
PR binutils/26301
* configure: Regenerated.
gdb/
PR binutils/26301
* configure: Regenerated.
It is quite normal to have headers without library on multilib OSes.
Add AC_TRY_LINK to PKG_CHECK_MODULES to check if $pkg_cv_[]$1[]_LIBS
works.
config/
PR binutils/26301
* pkg.m4 (PKG_CHECK_MODULES): Add AC_TRY_LINK to check if
$pkg_cv_[]$1[]_LIBS works.
binutils/
PR binutils/26301
* configure: Regenerated.
gdb/
PR binutils/26301
* configure: Regenerated.
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.
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.
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.
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.
gdb_select.h and the event loop require some configure checks, so this
moves the needed checks to common.m4 and updates the configure
scripts.
gdb/ChangeLog
2020-04-13 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
* configure.ac: Remove checks that are now in GDB_AC_COMMON.
gdbserver/ChangeLog
2020-04-13 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
* config.in: Rebuild.
gdbsupport/ChangeLog
2020-04-13 Tom Tromey <tom@tromey.com>
* config.in, configure: Rebuild.
* common.m4 (GDB_AC_COMMON): Check for poll.h, sys/poll.h,
sys/select.h, and poll.
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.
While working on the preceding selftests patches, I noticed that some
selftests-specific files are included in the build even when selftests
are disabled, namely disasm-selftest.c and gdbarch-selftests.c. These
files are entirely #if'ed out when building with selftests disabled.
This is not a huge problem, but I think it would make more sense if
these files were simply not built.
With this patch, I propose to put all the selftests-specific source
files into a SELFTESTS_SRCS Makefile variable (even selftest-arch.c,
which is currently added by the configure script).
gdb/ChangeLog:
* Makefile.in (SUBDIR_UNITTESTS_SRCS): Rename to...
(SELFTESTS_SRCS): ... this. Add disasm-selftests.c,
gdbarch-selfselftests.c and selftest-arch.c.
(SUBDIR_UNITTESTS_OBS): Rename to...
(SELFTESTS_OBS): ... this.
(COMMON_SFILES): Remove disasm-selftests.c and
gdbarch-selftests.c.
* configure.ac: Don't add selftest-arch.{c,o} to
CONFIG_{SRCS,OBS}.
* disasm-selftests.c, gdbarch-selftests.c: Remove GDB_SELF_TEST
preprocessor conditions.
