Stop using AC_HEADER_STDC since it is no longer supported in autoconf
2.72+. We require a C++ compiler that supports c++17, it's probably
safe to assume that the C compiler fully supports C89.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Add a few -Wunused-* diagnostic flags that look useful. Some are known
to gcc, some to clang, some to both. Fix the fallouts.
-Wunused-const-variable=1 is understood by gcc, but not clang.
-Wunused-const-variable would be undertsood by both, but for gcc at
least it would flag the unused const variables in headers. This doesn't
make sense to me, because as soon as one source file includes a header
but doesn't use a const variable defined in that header, it's an error.
With `=1`, gcc only warns about unused const variable in the main source
file. It's not a big deal that clang doesn't understand it though: any
instance of that problem will be flagged by any gcc build.
Change-Id: Ie20d99524b3054693f1ac5b53115bb46c89a5156
Approved-By: Tom Tromey <tom@tromey.com>
UST support in gdbserver is substantially outdated. Simon says:
...[having HAVE_UST defined] never happens nowadays because it used
a version of lttng-ust that has been deprecated for a loooong time
(the 0.x series). So everything in HAVE_UST just bitrots. It might
be possible to update all this code to use lttng-ust 2.x (1.x never
existed), but I don't think it's going to happen unless somebody
specifically asks for it. I would suggest removing support for UST
from gdbserver. ...If we ever want to resurrect the support for UST
and port to 2.x, we can get the code from the git history.
This patch removes the support, mostly mechanically by deleting code
guarded by `#ifdef HAVE_UST`. After these removals, `struct
static_tracepoint_ctx` becomes unused. So, remove it, too.
The following patches remove more code.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This makes the lists easier sort read and modify. There are no changes
in the generated config.h files, so I'm confident this brings no
functional changes.
Change-Id: Ib6b7fc532bcd662af7dbb230070fb1f4fc75f86b
By default GDB will be printing the hex payload of the ptwrite package as
auxiliary information. To customize this, the user can register a ptwrite
filter function in python, that takes the payload and the PC as arguments and
returns a string which will be printed instead. Registering the filter
function is done using a factory pattern to make per-thread filtering easier.
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
Now that all known uses of VLAs within GDB are removed, remove the
`-Wno-vla-cxx-extension` (which was used to silence clang warnings) and
add `-Wvla`, such that any use of a VLA will trigger a warning.
Change-Id: I69a8d7f93f973743165b0ba46f9c2ea8adb89025
Reviewed-By: Keith Seitz <keiths@redhat.com>
Currently, if you configure gdb with explicit --enable-threading, but
then configure detects std::thread does not work, configure silently
disables threading support and continues configuring.
This patch makes that scenario cause a configuration error, like so:
$ /home/pedro/gdb/src/configure --enable-threading && make
...
configure: error: std::thread does not work; disable threading
make[1]: *** [Makefile:11225: configure-gdbsupport] Error 1
make[1]: Leaving directory '/home/pedro/gdb/build-windows-threads'
make: *** [Makefile:1041: all] Error 2
$
Additionally, if you don't explicitly pass --enable-threading, and
std::thread does not work, we will now get a warning (and the build
continues):
$ /home/pedro/gdb/src/configure && make
...
configure: WARNING: std::thread does not work; disabling threading
...
This is similar to how we handle --enable-tui and missing curses. The
code and error/warning messages were borrowed from there.
Change-Id: I73a8b580d1e2a796b23136920c0e181408ae1b22
Approved-By: Tom Tromey <tom@tromey.com>
With a x86_64-pc-mingw32 toolchain there is a build issue
whether or not the --disable-threading option is used.
The problem happens because _WIN32_WINNT is defined to 0x501
before #include <mutex> which makes the compilation abort
due to missing support for __gthread_cond_t in std_mutex.h,
which is conditional on _WIN32_WINNT >= 0x600.
Fix the case when --disable-threading is used, by only
including <mutex> in gdb/complaints.c when STD_CXX_THREAD
is defined.
Additionally make the configure script try to #include <mutex>
to automatically select --disable-threading when the header file
is not able to compile.
Approved-By: Tom Tromey <tom@tromey.com>
When building with clang 18, I see:
CXX aarch64-linux-tdep.o
/home/smarchi/src/binutils-gdb/gdb/aarch64-linux-tdep.c:1299:26: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
1299 | gdb_byte za_zeroed[za_bytes];
| ^~~~~~~~
/home/smarchi/src/binutils-gdb/gdb/aarch64-linux-tdep.c:1299:26: note: read of non-const variable 'za_bytes' is not allowed in a constant expression
/home/smarchi/src/binutils-gdb/gdb/aarch64-linux-tdep.c:1282:10: note: declared here
1282 | size_t za_bytes = std::pow (sve_vl_from_vg (svg), 2);
| ^
Since we are using VLAs right now, that warning doesn't make sense for
us. add `-Wno-vla-cxx-extension` to the list of warning flags we try to
enable. If we ever choose to disallow VLAs, we can remove that flag.
Change-Id: Ie41feafc50c343f6e75333d4f836ce32fbeb6d8c
Make gdbserver's build system locate libiconv when building for Linux.
Commit 07b3255c3b ("Filter invalid encodings from Linux thread names")
make libiconv madantory for building gdbserver on Linux.
While trying to cross-compile gdb for xtensa-fsf-linux-uclibc (with a
toolchain generated with crosstool-ng), I got:
/home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:48:10: fatal error: iconv.h: No such file or directory
48 | #include <iconv.h>
| ^~~~~~~~~
I downloaded GNU libiconv, built it for that host, and installed it in
an arbitrary directory. I had to modify the gdbserver build system to
locate libiconv and use it, the result is this patch.
I eventually found that crosstool-ng has a config option to make uclibc
provide an implementation of iconv, which is of course much easier. But
given that this patch is now written, I think it would be worth merging
it, it could help some people who do not have iconv built-in their libc
in the future (and may not have the luxury of rebuilding their libc like
I do).
Using AM_ICONV in configure.ac adds these options for configure (the
same we have for gdb):
--with-libiconv-prefix[=DIR] search for libiconv in DIR/include and DIR/lib
--without-libiconv-prefix don't search for libiconv in includedir and libdir
--with-libiconv-type=TYPE type of library to search for (auto/static/shared)
It sets the `LIBICONV` variable with whatever is needed to link with
libiconv, and adds the necessary `-I` flag to `CPPFLAGS`.
To avoid unnecessarily linking against libiconv on hosts that don't need
it, set `MAYBE_LIBICONV` with the contents of `LIBICONV` only if the
host is Linux, and use `MAYBE_LIBICONV` in `Makefile.in`.
Since libiconv is a hard requirement for Linux hosts, error out if it is
not found.
The bits in acinclude.m4 are similar to what we have in
gdb/acinclude.m4.
Update the top-level build system to support building against an in-tree
libiconv (I did not test this part though). Something tells me that the
all-gdbserver dependency on all-libiconv is unnecessary, since there is
already a dependency of configure-gdbserver on all-libiconv (and
all-gdbserver surely depends on configure-gdbserver). I just copied
what's done for GDB though.
ChangeLog:
* Makefile.def: Add configure-gdbserver and all-gdbserver
dependencies on all-libiconv.
* Makefile.in: Re-generate.
Change-Id: I90f8ef88dd4917df5a68b45550d93622fc9cfed4
Approved-By: Tom Tromey <tom@tromey.com>
This changes the various gdb-related directories to use
-Wimplicit-fallthrough=5, meaning that only the fallthrough attribute
can be used in switches -- special 'fallthrough' comments will no
longer be usable.
Approved-By: Pedro Alves <pedro@palves.net>
This patch proposes to require a C++17 compiler to build gdb /
gdbsupport / gdbserver. Before this patch, GDB required a C++11
compiler.
The general policy regarding bumping C++ language requirement in GDB (as
stated in [1]) is:
Our general policy is to wait until the oldest compiler that
supports C++NN is at least 3 years old.
Rationale: We want to ensure reasonably widespread compiler
availability, to lower barrier of entry to GDB contributions, and to
make it easy for users to easily build new GDB on currently
supported stable distributions themselves. 3 years should be
sufficient for latest stable releases of distributions to include a
compiler for the standard, and/or for new compilers to appear as
easily installable optional packages. Requiring everyone to build a
compiler first before building GDB, which would happen if we
required a too-new compiler, would cause too much inconvenience.
See the policy proposal and discussion
[here](https://sourceware.org/ml/gdb-patches/2016-10/msg00616.html).
The first GCC release which with full C++17 support is GCC-9[2],
released in 2019[3], which is over 4 years ago. Clang has had C++17
support since Clang-5[4] released in 2018[5].
A discussions with many distros showed that a C++17-able compiler is
always available, meaning that this no hard requirement preventing us to
require it going forward.
[1] https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#When_is_GDB_going_to_start_requiring_C.2B-.2B-NN_.3F
[2] https://gcc.gnu.org/projects/cxx-status.html#cxx17
[3] https://gcc.gnu.org/gcc-9/
[4] https://clang.llvm.org/cxx_status.html
[5] https://releases.llvm.org/
Change-Id: Id596f5db17ea346e8a978668825787b3a9a443fd
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Pedro Alves <pedro@palves.net>
A user pointed out that the -lsocket check in gdb should also apply to
gdbserver -- otherwise it can't find the Solaris socketpair. This
patch makes the change. It also removes a couple of redundant
function checks from gdb's configure.ac.
This was tested by the person who reported the bug.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30927
Approved-By: Pedro Alves <pedro@palves.net>
GCC recently added support for the Windows thread model, enabling
libstdc++ to support Windows natively. However, this supporrt
requires a version of Windows later than the minimum version that is
supported by GDB.
PR build/29966 points out that the GDB configure test for std::thread
does not work in this situation, because _WIN32_WINNT is not defined
in test program, and so <thread> seems to be fine.
This patch is an attempt to fix the problem, by using the same setting
for _WIN32_WINNT at configure time as is used at build time.
I don't have access to one of the older systems so I don't think I can
truly test this. I did do a mingw cross build, though. I'm going to
ask the bug reporter to test it.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29966
The following patch moves the fast_hash function, which uses libxxhash,
to gdbsupport. Move the libxxhash configure check to gdbsupport (and
transitively to gdbserver).
Change-Id: I242499e50c8cd6fe9f51e6e92dc53a1b3daaa96e
Approved-By: Andrew Burgess <aburgess@redhat.com>
Currently, the configure check for std::thread relies on pthreads
existing. However, this means that if std::thread is implemented for
a non-pthreads host, then the check will yield the wrong answer. This
happened in AdaCore internal builds. Here, we have this GCC patch:
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html
... which adds mingw support to GCC's gthreads implementation, and
also to std::thread.
This configure change fixes this problem and enables threading for
gdb.
This commit aims to not make use of -Wmissing-prototypes when
compiling with g++.
Use of -Wmissing-prototypes was added with this commit:
commit a0761e34f0
Date: Wed Mar 11 15:15:12 2020 -0400
gdb: enable -Wmissing-prototypes warning
Because clang can provide helpful warnings with this flag.
Unfortunately, g++ doesn't accept this flag, and will give this
warning:
cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++
In theory the fact that this flag is not supported should be detected
by the configure check in gdbsupport/warning.m4, but for users of
ccache, this check doesn't work due to a long standing ccache issue:
https://github.com/ccache/ccache/issues/738
The ccache problem is that -W... options are reordered on the command
line, and so -Wmissing-prototypes is seen before -Werror. Usually
this doesn't matter, but the above warning (about the flag not being
valid) is issued before the -Werror flag is processed, and so is not
fatal.
There have been two previous attempts to fix this that I'm aware of.
The first is:
https://sourceware.org/pipermail/gdb-patches/2021-September/182148.html
In this attempt, instead of just relying on a compile to check if a
flag is valid, the proposal was to both compile and link. As linking
doesn't go through ccache, we don't suffer from the argument
reordering problem, and the link phase will correctly fail when using
-Wmissing-prototypes with g++. The configure script will then disable
the use of this flag.
This approach was rejected, and the suggestion was to only add the
-Wmissing-prototypes flag if we are compiling with gcc.
The second attempt, attempts this approach, and can be found here:
https://sourceware.org/pipermail/gdb-patches/2021-November/183076.html
This attempt only adds the -Wmissing-prototypes flag is the value of
GCC is not 'yes'. This feels like it is doing the right thing,
unfortunately, the GCC flag is really a 'is gcc like' flag, not a
strict, is gcc check. As such, GCC is set to 'yes' for clang, which
would mean the flag was not included for clang or gcc. The entire
point of the original commit was to add this flag for clang, so
clearly the second attempt is not sufficient either.
In this new attempt I have added gdbsupport/compiler-type.m4, this
file defines AM_GDB_COMPILER_TYPE. This macro sets the variable
GDB_COMPILER_TYPE to either 'gcc', 'clang', or 'unknown'. In future
the list of values might be extended to cover other compilers, if this
is ever useful.
I've then modified gdbsupport/warning.m4 to only add the problematic
-Wmissing-prototypes flag if GDB_COMPILER_TYPE is not 'gcc'.
I've tested this with both gcc and clang and see the expected results,
gcc no longer attempts to use the -Wmissing-prototypes flag, while
clang continues to use it.
When compiling using ccache, I am no longer seeing the warning.
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 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.
I get some diffs when running autoconf in gdbserver, probably leftovers
from commit 5dfe4bfcb9 ("Fix format_pieces selftest on Windows").
Re-generate configure in that directory.
Change-Id: Icdc9906af95fbaf1047a579914b2983f8ec5db08
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
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.
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.
... with AC_COMPILE_IFELSE and AC_LANG_PROGRAM.
All changes in the generated configure file are insignificant
whitespace changes.
gdbserver/ChangeLog:
* acinclude.m4: Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE +
AC_LANG_PROGRAM.
* configure: Re-generate.
Change-Id: Idab8b5e1a984046b5283940c02e5a22da2291d58
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 gdbserver/configure.ac and then tweak it to use easier
to read indentation. This removes a few warnings when running
`autoreconf -vf -Wall`.
* Replace AC_INIT with AC_INIT and no arguments plus AC_CONFIG_SRCDIR.
* Replace AC_GNU_SOURCE with AC_USE_SYSTEM_EXTENSIONS.
* Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE.
* Replace AC_TRY_LINK with AC_LINK_IFELSE.
autoupdate gets it right, except this one here:
--- a/gdbserver/configure.ac
+++ b/gdbserver/configure.ac
@@ -304,7 +304,7 @@ if test "$srv_linux_thread_db" = "yes"; then
AC_LINK_IFELSE([AC_LANG_PROGRAM([[]], [[]])],[found="-Wl,--dynamic-list"
RDYNAMIC='-Wl,--dynamic-list=$(srcdir)/proc-service.list'],[RDYNAMIC="-rdynamic"
LDFLAGS="$old_LDFLAGS $RDYNAMIC"
- AC_TRY_LINK([], [],
+ _au_m4_changequote([,])AC_TRY_LINK([], [],
[found="-rdynamic"],
[found="no"
RDYNAMIC=""])])
... which I had to convert manually.
The changes in the generated configure file only contain insignificant
whitespace changes, so that gives confidence that the conversion is
correct.
gdbserver/ChangeLog:
* configure.ac: Modernize.
* configure: Re-generate.
Change-Id: Ia769aaec2aafac595504f477da955e91dffa4d8f
`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
I get this diff when I re-generate the configure script in gdbserver,
probably leftovers from e911c6663b ("Require kinfo_get_file and
kinfo_get_vmmap for FreeBSD hosts").
gdbserver/ChangeLog:
* config.in: Re-generate.
* configure: Re-generate.
Change-Id: Id19a72ea9f3e7c7b4fdb0f319c9c0bbad0e39aeb
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.
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 port has been unmaintained for years, remove it.
gdbserver/ChangeLog:
* configure: Re-generate.
* configure.ac: Remove srv_qnx test.
* configure.srv: Remove nto case.
* nto-low.cc, nto-low.h, nto-x86-low.cc: Remove.
* remote-utils.c: Remove __QNX__-guarded code.
Change-Id: I8a1ad9c740a69352da1f6993778dbf951eebb22f
This port has been unmaintained for years, remove it.
gdbserver/ChangeLog:
* configure: Re-generate.
* configure.ac: Remove srv_lynxos test.
* configure.srv: Remove lynxos cases.
* lynx-i386-low.cc, lynx-low.cc, lynx-low.h, lynx-ppc-low.c:
Remove.
Change-Id: I239d1cf1fc7b4c7a174251bc7981707eaba7d972
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.
This changes the gdbserver build to use the gdbsupport that was built
for gdb.
gdbserver and gdbreplay now must use WIN32APILIBS (aka -lws2_32).
Before this change, gdbserver did not define USE_WIN32API when
building gdbsupport, but now this is always done.
ChangeLog
2020-03-12 Tom Tromey <tom@tromey.com>
* Makefile.in: Rebuild.
* Makefile.def (gdbserver): Depend on gdbsupport.
gdbserver/ChangeLog
2020-03-12 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
* configure.ac (GDBSERVER_DEPFILES): Remove srv_selftest_objs.
(WIN32APILIBS): New subst.
* Makefile.in (SFILES, OBS, TAGS, GDBREPLAY_OBS): Remove
gdbsupport files.
(gdbsupport/%.o): Remove target.
(GDBSUPPORT_BUILDDIR, GDBSUPPORT): New variables.
(gdbserver$(EXEEXT), gdbreplay$(EXEEXT)): Add GDBSUPPORT.
(WIN32APILIBS): New variable.
(gdbserver$(EXEEXT)): Add WIN32APILIBS.
(gdbreplay$(EXEEXT)): Likewise.
gdbserver uses gdb's alloc.c, and this in turn can include headers
from intl via gdbsupport/gdb_locale.h. This can cause build failures
in some situations, for example if you build gdb and gdbserver on
mingw.
This patch restores the gdbsupport dependency on intl, and changes
gdbserver to use ZW_GNU_GETTEXT_SISTER_DIR. This fixes this build
problem.
ChangeLog
2020-03-12 Tom Tromey <tom@tromey.com>
* Makefile.in: Rebuild.
* Makefile.def (gdbsupport): Depend on intl.
gdbserver/ChangeLog
2020-03-12 Tom Tromey <tom@tromey.com>
* config.in, configure: Rebuild.
* configure.ac: Call ZW_GNU_GETTEXT_SISTER_DIR.
* acinclude.m4: Include gettext-sister.m4.
* Makefile.in (top_builddir, INTL, INTL_DEPS, INTL_CFLAGS): New
variables.
(INCLUDE_CFLAGS): Add INTL_CFLAGS.
(gdbserver$(EXEEXT), gdbreplay$(EXEEXT)): Use INTL_DEPS, INTL.
The same is done for gdb, gdbserver and gdbsupport. I therefore think
it makes sense to move that to GDB_AC_COMMON.
It is required to move the call to GDB_AC_COMMON so it is before
GDB_AC_SELFTEST in gdbserver/configure.ac, otherwise the $development
variable isn't set when the code behind GDB_AC_SELFTEST executes.
gdb/ChangeLog:
* configure.ac: Don't source bfd/development.sh.
* selftest.m4: Modify comment.
* configure: Re-generate.
gdbserver/ChangeLog:
* configure.ac: Don't source bfd/development.sh, move
GDB_AC_COMMON higher.
* configure: Re-generate.
gdbsupport/ChangeLog:
* configure.ac: Don't source bfd/development.sh.
* common.m4: Source bfd/development.sh.
* configure: Re-generate.
