GDB's compile subsystem is deeply tied to GDB's ability to understand
DWARF. A future patch will add the option to disable DWARF at configure
time, but for that to work, the compile subsystem will need to be
entirely disabled as well, so this patch adds that possibility.
I also think there is motive for a security conscious user to disable
compile for it's own sake. Considering that the code is quite
unmaintained, and depends on an equally unmaintained gcc plugin, there
is a case to be made that this is an unnecessary increase in the attack
surface if a user knows they won't use the subsystem. Additionally, this
can make compilation slightly faster and the final binary is around 3Mb
smaller. But these are all secondary to the main goal of being able to
disable dwarf at configure time.
To be able to achieve optional compilation, some of the code that
interfaces with compile had to be changed. All parts that directly
called compile things have been wrapped by ifdefs checking for compile
support. The file compile/compile.c has been setup in a similar way to
how python's and guile's main file has been setup, still being compiled
but only for with placeholder command.
Finally, to avoid several new errors, a new TCL proc was introduced to
gdb.exp, allow_compile_tests, which checks if the "compile" command is
recognized before the inferior is started and otherwise skips the compile
tests. All tests in the gdb.compile subfolder have been updated to use
that, and the test gdb.base/filename-completion also uses this. The proc
skip_compile_feature_tests to recognize when the subsystem has been
disabled at compile time.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
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>
Update the gdb-add-index script to offer --help and --version options.
The script currently accepts the argument '-dwarf-5' with a single
leading '-'. As two '--' is more common for long options, the
preferred argument form is now '--dwarf-5', the docs have been
updated, and the new help text uses this form.
For backward compatibility, the old '-dwarf-5' form is still
accepted.
The new arguments are '--help' or '-h', but I also accept '-help' for
consistency with '-dwarf-5'. And likewise for the version argument.
Handling of the gdb-add-index script is done basically the same as for
gcore and gstack; we use config.status to create a .in file within the
build directory, which is then processed by the Makefile to create the
final script.
The difference with gdb-add-index is that I left the original script
as gdb/contrib/gdb-add-index.sh rather than renaming it to something
like gdb/contrib/gdb-add-index-1.in, which is how gcore and gstack are
handled (though they are not in the contrib directory).
The reason for this is that the contrib/cc-with-tweaks.sh script looks
for gdb-add-index.sh within the gdb/contrib/ source directory.
As the only reason we process gdb-add-index.sh into the build
directory is to support the PKGVERSION and VERSION variables, allowing
cc-with-tweaks to continue using the unprocessed version seems
harmless, and avoids having to change cc-with-tweaks.sh at all.
I tested that I can still run tests using the cc-with-gdb-index target
board, and that the installed gdb-add-index script correctly shows a
version number when asked.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32325
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
Based on the work in this commit:
commit fb2ded33c1e519659743047ed7817166545b6d91
Date: Fri Dec 20 12:46:11 2024 -0800
Add gstack script
This commit adds a '-v' or '--version' option to the existing gcore
script. This new option causes the script to print its version
number, and then exit.
I needed to adjust the getopts handling a little in order to support
the long form '--version' argument, but as this makes gcore more
consistent with gstack, then this seems like a good thing.
The usage message is now getting a little long. Don't worry, I plan
to clean that up in the next commit.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32325
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
The recent commit b601c58034ed755fb765fc13782b6876bffd25d4 causes the
gdb configure to fail if --enable-targets=all was requested, but 64 bit
bfd was not enabled. This was due to a build failure first reported
against mips, and that I also encountered building on a 32 bit mips
system, but that looked like a general failure.
Further examination showed that this is, in fact, mips-specific (or at
least, not completely generic) as other targets like debian-i386 and
32-bit arm could build all targets just fine.
This commit restricts the new error to only trigger in mips hosts.
Approved-By: Andrew Burgess <aburgess@redhat.com>
As PR sim/28684 explains, it isn't possible to compile GDB with all
targets enabled and not enabling 64 bit bfd. In 64 bit hosts, 64 bit bfd
is forced, so the build works, but in 32 bit hosts, that has to be
explicitly enabled.
I ran into this when I tried compiling GDB on a mips64 machine running a
32 bit OS. Along with the errors in the PR, several other architectures
are also required, notably aarch64 and other explicitly 64bit targets.
Additionally, some 32 bit files required for the gdb mips target aren't
added to the makefile.
Considering the last comment in the bug says this isn't going to be
fixed on the binutils side, I didn't think it was worth trying to fix
the GDB side. Instead, this commit causes the configure script to fail
if all targets were requested and 64 bit bfd isn't enabled. If that is
ever fixed, we can revert this commit.
I considered adding this to the top level configure script, but couldn't
figure out how to detect the situation in there, so this was my next
best idea.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28684
Approved-by: Kevin Buettner <kevinb@redhat.com>
This commit adds support for a `gstack' command which Fedora has
been carrying for many years. gstack is a natural counterpart to
the gcore command. Whereas gcore dumps a core file, gstack prints
stack traces of a running process.
There are many improvements over Fedora's version of this script.
The dependency on procfs is gone; gstack will run anywhere gdb
runs. The only runtime dependencies are bash and awk.
The script includes suggestions from gdb/32325 to include
versioning and help. [If this approach to gdb/32325 is acceptable,
I could propagate the solution to gcore/gdb-add-index.]
I've rewritten the documentation, integrating it into the User Manual.
The manpage is now output using this one source.
Example run (on x86_64 Fedora 40)
$ gstack --help
Usage: gstack [-h|--help] [-v|--version] PID
Print a stack trace of a running program
-h, --help Print this message then exit.
-v, --version Print version information then exit.
$ gstack -v
GNU gstack (GDB) 16.0.50.20241119-git
$ gstack 12345678
Process 12345678 not found.
$ gstack $(pidof emacs)
Thread 6 (Thread 0x7fd5ec1c06c0 (LWP 2491423) "pool-spawner"):
#0 0x00007fd6015ca3dd in syscall () at /lib64/libc.so.6
#1 0x00007fd60b31eccd in g_cond_wait () at /lib64/libglib-2.0.so.0
#2 0x00007fd60b28a61b in g_async_queue_pop_intern_unlocked () at /lib64/libglib-2.0.so.0
#3 0x00007fd60b2f1a03 in g_thread_pool_spawn_thread () at /lib64/libglib-2.0.so.0
#4 0x00007fd60b2f0813 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5 0x00007fd6015486d7 in start_thread () at /lib64/libc.so.6
#6 0x00007fd6015cc60c in clone3 () at /lib64/libc.so.6
#7 0x0000000000000000 in ??? ()
Thread 5 (Thread 0x7fd5eb9bf6c0 (LWP 2491424) "gmain"):
#0 0x00007fd6015be87d in poll () at /lib64/libc.so.6
#1 0x0000000000000001 in ??? ()
#2 0xffffffff00000001 in ??? ()
#3 0x0000000000000001 in ??? ()
#4 0x000000002104cfd0 in ??? ()
#5 0x00007fd5eb9be320 in ??? ()
#6 0x00007fd60b321c34 in g_main_context_iterate_unlocked.isra () at /lib64/libglib-2.0.so.0
Thread 4 (Thread 0x7fd5eb1be6c0 (LWP 2491425) "gdbus"):
#0 0x00007fd6015be87d in poll () at /lib64/libc.so.6
#1 0x0000000020f9b558 in ??? ()
#2 0xffffffff00000003 in ??? ()
#3 0x0000000000000003 in ??? ()
#4 0x00007fd5d8000b90 in ??? ()
#5 0x00007fd5eb1bd320 in ??? ()
#6 0x00007fd60b321c34 in g_main_context_iterate_unlocked.isra () at /lib64/libglib-2.0.so.0
Thread 3 (Thread 0x7fd5ea9bd6c0 (LWP 2491426) "emacs"):
#0 0x00007fd6015ca3dd in syscall () at /lib64/libc.so.6
#1 0x00007fd60b31eccd in g_cond_wait () at /lib64/libglib-2.0.so.0
#2 0x00007fd60b28a61b in g_async_queue_pop_intern_unlocked () at /lib64/libglib-2.0.so.0
#3 0x00007fd60b28a67c in g_async_queue_pop () at /lib64/libglib-2.0.so.0
#4 0x00007fd603f4d0d9 in fc_thread_func () at /lib64/libpangoft2-1.0.so.0
#5 0x00007fd60b2f0813 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#6 0x00007fd6015486d7 in start_thread () at /lib64/libc.so.6
#7 0x00007fd6015cc60c in clone3 () at /lib64/libc.so.6
#8 0x0000000000000000 in ??? ()
Thread 2 (Thread 0x7fd5e9e6d6c0 (LWP 2491427) "dconf worker"):
#0 0x00007fd6015be87d in poll () at /lib64/libc.so.6
#1 0x0000000000000001 in ??? ()
#2 0xffffffff00000001 in ??? ()
#3 0x0000000000000001 in ??? ()
#4 0x00007fd5cc000b90 in ??? ()
#5 0x00007fd5e9e6c320 in ??? ()
#6 0x00007fd60b321c34 in g_main_context_iterate_unlocked.isra () at /lib64/libglib-2.0.so.0
Thread 1 (Thread 0x7fd5fcc45280 (LWP 2491417) "emacs"):
#0 0x00007fd6015c9197 in pselect () at /lib64/libc.so.6
#1 0x0000000000000000 in ??? ()
Since this is essentially a complete rewrite of the original
script and documentation, I've chosen to only keep a 2024 copyright date.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
The mingw-w64 build breaks currently:
...
In file included from gdb/cli/cli-cmds.c:58:
gdbsupport/eintr.h: In function ‘pid_t gdb::waitpid(pid_t, int*, int)’:
gdbsupport/eintr.h:77:35: error: ‘::waitpid’ has not been declared; \
did you mean ‘gdb::waitpid’?
77 | return gdb::handle_eintr (-1, ::waitpid, pid, wstatus, options);
| ^~~~~~~
| gdb::waitpid
gdbsupport/eintr.h:75:1: note: ‘gdb::waitpid’ declared here
75 | waitpid (pid_t pid, int *wstatus, int options)
| ^~~~~~~
...
This is a regression since commit 658a03e9e85 ("[gdbsupport] Add
gdb::{waitpid,read,write,close}"), which moved the use of ::waitpid from
run_under_shell, where it was used conditionally:
...
#if defined(CANT_FORK) || \
(!defined(HAVE_WORKING_VFORK) && !defined(HAVE_WORKING_FORK))
...
#else
...
int ret = gdb::handle_eintr (-1, ::waitpid, pid, &status, 0);
...
to gdb::waitpid, where it's used unconditionally:
...
inline pid_t
waitpid (pid_t pid, int *wstatus, int options)
{
return gdb::handle_eintr (-1, ::waitpid, pid, wstatus, options);
}
...
Likewise for ::wait.
Guard these uses with HAVE_WAITPID and HAVE_WAIT.
Reproduced and tested by doing a mingw-w64 cross-build on x86_64-linux.
Reported-By: Simon Marchi <simark@simark.ca>
Co-Authored-By: Tom de Vries <tdevries@suse.de>
The comment says this is for HP/UX, which is no longer supported. There
should be no functional changes with this, since nothing checks
HAVE_ELF_HP_H.
Change-Id: Ie897fc64638c9fea28463e1bf69e450c3673fd84
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
Eli mentioned [1] that given that we use US English spelling in our
documentation, we should use "behavior" instead of "behaviour".
In wikipedia-common-misspellings.txt there's a rule:
...
behavour->behavior, behaviour
...
which leaves this as a choice.
Add an overriding rule to hardcode the choice to common-misspellings.txt:
...
behavour->behavior
...
and add a rule to rewrite behaviour into behavior:
...
behaviour->behavior
...
and re-run spellcheck.sh on gdb*.
Tested on x86_64-linux.
[1] https://sourceware.org/pipermail/gdb-patches/2024-November/213371.html
Include the value of configuration flag --enable-targets in the output
of GDB command 'show configuration' and also in the output printed for
'gdb --configuration'. This will make it easier to see how GDB was
built.
No tests added or updated as we can't really check for a specific flag
appearing or not appearing on the configuration output. But we do
print the configuration within lib/gdb.exp to check which features are
built into GDB, so if this change broke configuration printing then
plenty of tests should stop working (they don't).
Approved-By: Tom Tromey <tom@tromey.com>
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>
amd-dbgapi 0.75 (from ROCm release 6.2.0) brings a few backwards
incompatible changes. Adjust the amd-dbgapi target code accordingly.
Given that the AMD GPU port in upstream GDB today is of limited use
(it's still missing important pieces), we don't really care about
supporting amd-dbgapi versions other than the latest stable one, so no
effort is made to keep compatibility with versions 6.1.2 and older.
The changes are:
- AMD_DBGAPI_EXCEPTION_WAVE_APERTURE_VIOLATION was renamed to
AMD_DBGAPI_EXCEPTION_WAVE_ADDRESS_ERROR (the old name still exists
but is deprecated), use the latter.
- In the callbacks structure, the get_os_pid callback was replaced with
client_process_get_info, which is more general and extensible.
Convert our get_os_pid to a new, equivalent, client_process_get_info
callback. Handle the new AMD_DBGAPI_CLIENT_PROCESS_INFO_CORE_STATE
query, but just return "not available".
- The xfer_global_memory callback was added to the callbacks structure,
add that new callback.
- Update configure.ac to check for amd-dbgapi >= 0.75.0.
Change-Id: If012398cf55ebf6146b007f6b4e8395dd48ef981
Approved-By: Lancelot Six <lancelot.six@amd.com>
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
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
Following the suggestion in this review comment:
https://inbox.sourceware.org/gdb-patches/9420bbb0-2614-4847-9157-8562f8a62d03@simark.ca
this commit realigns the AC_ARG_ENABLE(sim, ....) block. I've added
additional [...] quoting in a couple of places, which is inline with
how other AC_ARG_ENABLE blocks are formatted within GDB's configure.ac
file.
There should be no change in how GDB configures or builds after this
commit.
After the recent commits, I noticed that GDB's configure script would
still emit two lines even when run in silent mode. If you touch
gdb/Makefile.in and then run 'make all' in the gdb/ build directory
you'll see this:
GEN config.status
enable_sim = no
enableval = no
Obviously the 'no' might be 'yes' depending on how you actually
configured GDB.
This is caused by two direct invocations of 'echo' in GDB's
configure.ac script.
In this commit I replace these calls with use of AC_MSG_NOTICE
instead. Now when configure is run with the --silent command line
option these lines will not be printed.
There should be no changes in the built GDB after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
In gdb/configure the line:
...
$development || tentative_python_cflags="$tentative_python_cflags -DNDEBUG"
...
intends to ensure that -DNDEBUG is added to the python flags of a release
build.
However, when building gdb-14-branch we have:
...
configure:22024: checking compiler flags for python code
...
configure:22047: result: -fno-strict-aliasing -fwrapv
...
This is a regression since commit db6878ac553 ("Move sourcing of development.sh
to GDB_AC_COMMON"), which introduced a reference before assignment:
...
$development || tentative_python_cflags="$tentative_python_cflags -DNDEBUG"
...
. $srcdir/../bfd/development.sh
...
and consequently -DNDEBUG is never added.
[ This was not obvious to me, but apparently evaluating an empty or undefined
variable in this context is similar to using ':' or 'true', so the line is
evaluated as:
...
true || tentative_python_cflags="$tentative_python_cflags -DNDEBUG"
... ]
Fix this by moving GDB_AC_COMMON up in gdb/configure.ac, similar to how that
was done for gdbserver/configure.ac in commit db6878ac553.
[ Unfortunately, the move might introduce issues similar to the one we're
fixing, and I'm not sure how to check for this. Shellcheck doesn't detect
this type of problem. FWIW, I did run shellcheck (using arguments -xa, in the
src/gdb directory to make sure ../bfd/development.sh is taken into account)
before and after and observed that the number of lines/words/chars in the
shellcheck output is identical. ]
Build & tested on top of trunk.
Also build on top of gdb-14-branch, and observed this in gdb/config.log:
...
configure:25214: checking compiler flags for python code
...
configure:25237: result: -fno-strict-aliasing -fwrapv -DNDEBUG
...
Approved-By: Tom Tromey <tom@tromey.com>
PR build/31099
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31099
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>
This patch upgrades gdb/ax_cxx_compile_stdcxx.m4 to follow changes
available in [1] and regenerates the configure script.
[1] https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx.html
Change-Id: I5b16adc65c9e48a13ad65202d58ab7a9d487214e
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Pedro Alves <pedro@palves.net>
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>
If you want to install GDB in a custom prefix, have it look for debug info
in that prefix but also in the distro's default location (typically,
/usr/lib/debug) and run the GDB testsuite before doing "make install", you
have a bit of a problem:
Configuring GDB with '--prefix=$PREFIX' sets the GDB 'debug-file-directory'
parameter to $PREFIX/lib/debug. Unfortunately this precludes GDB from
looking for distro-installed debug info in /usr/lib/debug. For regular GDB
use you could set debug-file-directory to $PREFIX:/usr/lib/debug in
$PREFIX/etc/gdbinit so that GDB will look in both places, but if you want
to run the testsuite then that doesn't help because in that case GDB runs
with the '-nx' option.
There's the configure option '--with-separate-debug-dir' to set the default
value for 'debug-file-directory', but it accepts only one directory and not
a list. I considered modifying it to accept a list, but it's not obvious
how to do that because its value is also used by BFD, as well as processed
for "relocatability".
I thought it was simpler to add a new option to specify a list of
additional directories that will be appended to the debug-file-directory
setting.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
Add check for libdebuginfod 0.188 in AC_DEBUGINFOD and if found
define macro HAVE_LIBDEBUGINFOD_FIND_SECTION.
This macro indicates support for downloading ELF sections from
debuginfod servers.
This regenerates config files changed by the previous 44 commits.
Note that subject lines in these commits mostly match the gcc git
originating commit.
The tui border-kind setting allows values acs, ascii and space.
The values ascii and space however don't work well with !HAVE_WBORDER.
Fix this by removing the !HAVE_WBORDER case, which was introduced for Ultrix
support, which is now obsolete.
Tested on x86_64-linux.
PR tui/30580
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30580
Approved-By: Tom Tromey <tom@tromey.com>
Commit 5218fa9e8937b007d554f1e01c2e4ecdb9b7e271, "gdb: use libtool in
GDB_AC_CHECK_BFD" dropped passing in existing LDFLAGS. In our environment,
this caused the configure check "checking for ELF support in BFD" to stop
working causing build failures as we need our LDFLAGS to be used for
correct linking.
That change also meant the code failed to match the comments. Add back the
missing LDFLAGS preservation, fix our builds and match the comment.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Change-Id: Ie91509116fab29f95b9db1ff0b6ddc280d460112
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Reviewed-By: Jose E. Marchesi <jose.marchesi@oracle.com>
I noticed that the --disable-gdbmi option was broken for almost a year
(since 740b42ceb7c "gdb/python/mi: create MI commands using python").
The problem today is the python/py-cmd.c file. It is included in the
build if Python support is enabled, and it calls into some MI functions
(e.g. insert_mi_cmd_entry). If MI support is disabled, we get some
undefined symbols like:
mold: error: undefined symbol: insert_mi_cmd_entry(std::unique_ptr<mi_command, std::default_delete<mi_command> >)
>>> referenced by py-micmd.c
>>> python/py-micmd.o:(micmdpy_install_command(micmdpy_object*))
The python/py-cmd.c file should be included in the build if both Python
and MI support are enabled. It is not a case we support today, but it
could be done with a bit more configure code. However, I think we
should just remove the --disable-gdbmi option, and just include MI
support unconditionally.
Tom Tromey proposed a while ago to remove this option, but it ended
staying:
https://inbox.sourceware.org/gdb-patches/20180628172132.28843-1-tom@tromey.com/
However, there was no strong opposition to remove it. The argument was
just "bah, it doesn't hurt anybody".
But given today's case, I would rather remove complexity rather than add
some. I couldn't find anybody caring deeply for that option, and it's
not like MI adds any external dependency. It's just a bit more code.
Removing the option will not break anybody using --disable-gdbmi (it can
be found in many build scripts [1]), since we don't flag invalid
configure flags.
So, remove the option from configure.ac, and adjust Makefile.in
accordingly to always include the MI objects in the build.
[1] https://github.com/search?q=%22--disable-gdbmi%22&type=code
Change-Id: Ifcaa8c9fc4abc6fa686ed5fd984598644f745240
Approved-By: Tom Tromey <tom@tromey.com>
'gdb --configuration' does not mention if GDB was built with curses.
Since b5075fb68d4 (Rename to allow_tui_tests, 2023-01-08) it does show
--enable-tui (or --disable-tui), but one might want to know if GDB was
built with curses independently of the availability of the TUI.
Since configure.ac uses AC_SEARCH_LIBS to check for the curses library,
we do not get an automatically defined HAVE_LIBCURSES symbol in
config.in. We do have symbols defined by AC_CHECK_HEADERS
(HAVE_CURSES_H, etc.) but it would be cumbersome to use those in
print_gdb_configuration because we would have to check for all 6 symbols
corresponding the 6 headers listed. This would also increase the
maintenance burden if support for other variations of curses are added.
Instead, define 'HAVE_LIBCURSES' ourselves by adding an
'action-if-found' argument to AC_SEARCH_LIBS, and use it in
print_gdb_configuration.
While at it, remove the condition on 'ac_cv_search_waddstr' and set
'curses_found' directly in 'action-if-found'.
Change-Id: Id90e3d73990e169cee51bcc3e1d52072cfacd5b8
Approved-By: Simon Marchi <simon.marchi@efficios.com>
I suppose this was possible in the CVS days for the tui directory to be
missing, but it's not really possible nowaday. Well, a user could
delete the directory from their source tree but... it doesn't make
sense. Remove the check for that directory in configure.
Change-Id: Iea1412f5e5482ed003015030132ec22150c7d0b3
Approved-By: Tom Tromey <tom@tromey.com>
PR build/30108 concerns building gdb documentation with
--with-sytem-readline. If the in-tree readline directory is
missing, though, the docs will fail to build:
make[4]: Entering directory '/home/keiths/work/readline-doc-issue/linux/gdb/doc'
make[4]: *** No rule to make target '../../../src/gdb/doc/../../readline/readline/doc/rluser.texi', needed by 'gdb.info'. Stop.
The listed file (and hsuser.texi) are conditionally included by gdb.texinfo.
When system readline is used, gdb/configure.ac will leave
READLINE_TEXI_INCFLAGS empty, causing doc/Makefile.in to output a line to
$BUILD/doc/GDBvn.texi with "@set SYSTEM_READLINE". This surpresses the
inclusion of the missing files. They are not needed or used in this
scenario.
However, GDB_DOC_SOURCE_INCLUDES always lists these two files as dependencies,
thus provoking the build error whenever readline/ is missing.
This patch fixes this by creating (essentially) a conditional setting of the
dependencies to be included from readline.
Ensure that the "show configuration" command and the "--configuration"
command line switch shows if GDB was built with the AMDGPU support or
not.
This will be used in a later patch in this series.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This patch adds the foundation for GDB to be able to debug programs
offloaded to AMD GPUs using the AMD ROCm platform [1]. The latest
public release of the ROCm release at the time of writing is 5.4, so
this is what this patch targets.
The ROCm platform allows host programs to schedule bits of code for
execution on GPUs or similar accelerators. The programs running on GPUs
are typically referred to as `kernels` (not related to operating system
kernels).
Programs offloaded with the AMD ROCm platform can be written in the HIP
language [2], OpenCL and OpenMP, but we're going to focus on HIP here.
The HIP language consists of a C++ Runtime API and kernel language.
Here's an example of a very simple HIP program:
#include "hip/hip_runtime.h"
#include <cassert>
__global__ void
do_an_addition (int a, int b, int *out)
{
*out = a + b;
}
int
main ()
{
int *result_ptr, result;
/* Allocate memory for the device to write the result to. */
hipError_t error = hipMalloc (&result_ptr, sizeof (int));
assert (error == hipSuccess);
/* Run `do_an_addition` on one workgroup containing one work item. */
do_an_addition<<<dim3(1), dim3(1), 0, 0>>> (1, 2, result_ptr);
/* Copy result from device to host. Note that this acts as a synchronization
point, waiting for the kernel dispatch to complete. */
error = hipMemcpyDtoH (&result, result_ptr, sizeof (int));
assert (error == hipSuccess);
printf ("result is %d\n", result);
assert (result == 3);
return 0;
}
This program can be compiled with:
$ hipcc simple.cpp -g -O0 -o simple
... where `hipcc` is the HIP compiler, shipped with ROCm releases. This
generates an ELF binary for the host architecture, containing another
ELF binary with the device code. The ELF for the device can be
inspected with:
$ roc-obj-ls simple
1 host-x86_64-unknown-linux file://simple#offset=8192&size=0
1 hipv4-amdgcn-amd-amdhsa--gfx906 file://simple#offset=8192&size=34216
$ roc-obj-extract 'file://simple#offset=8192&size=34216'
$ file simple-offset8192-size34216.co
simple-offset8192-size34216.co: ELF 64-bit LSB shared object, *unknown arch 0xe0* version 1, dynamically linked, with debug_info, not stripped
^
amcgcn architecture that my `file` doesn't know about ----´
Running the program gives the very unimpressive result:
$ ./simple
result is 3
While running, this host program has copied the device program into the
GPU's memory and spawned an execution thread on it. The goal of this
GDB port is to let the user debug host threads and these GPU threads
simultaneously. Here's a sample session using a GDB with this patch
applied:
$ ./gdb -q -nx --data-directory=data-directory ./simple
Reading symbols from ./simple...
(gdb) break do_an_addition
Function "do_an_addition" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (do_an_addition) pending.
(gdb) r
Starting program: /home/smarchi/build/binutils-gdb-amdgpu/gdb/simple
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff5db7640 (LWP 1082911)]
[New Thread 0x7ffef53ff640 (LWP 1082913)]
[Thread 0x7ffef53ff640 (LWP 1082913) exited]
[New Thread 0x7ffdecb53640 (LWP 1083185)]
[New Thread 0x7ffff54bf640 (LWP 1083186)]
[Thread 0x7ffdecb53640 (LWP 1083185) exited]
[Switching to AMDGPU Wave 2:2:1:1 (0,0,0)/0]
Thread 6 hit Breakpoint 1, do_an_addition (a=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>,
b=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>,
out=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>) at simple.cpp:24
24 *out = a + b;
(gdb) info inferiors
Num Description Connection Executable
* 1 process 1082907 1 (native) /home/smarchi/build/binutils-gdb-amdgpu/gdb/simple
(gdb) info threads
Id Target Id Frame
1 Thread 0x7ffff5dc9240 (LWP 1082907) "simple" 0x00007ffff5e9410b in ?? () from /opt/rocm-5.4.0/lib/libhsa-runtime64.so.1
2 Thread 0x7ffff5db7640 (LWP 1082911) "simple" __GI___ioctl (fd=3, request=3222817548) at ../sysdeps/unix/sysv/linux/ioctl.c:36
5 Thread 0x7ffff54bf640 (LWP 1083186) "simple" __GI___ioctl (fd=3, request=3222817548) at ../sysdeps/unix/sysv/linux/ioctl.c:36
* 6 AMDGPU Wave 2:2:1:1 (0,0,0)/0 do_an_addition (
a=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>,
b=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>,
out=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>) at simple.cpp:24
(gdb) bt
Python Exception <class 'gdb.error'>: Unhandled dwarf expression opcode 0xe1
#0 do_an_addition (a=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>,
b=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>,
out=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>) at simple.cpp:24
(gdb) continue
Continuing.
result is 3
warning: Temporarily disabling breakpoints for unloaded shared library "file:///home/smarchi/build/binutils-gdb-amdgpu/gdb/simple#offset=8192&size=67208"
[Thread 0x7ffff54bf640 (LWP 1083186) exited]
[Thread 0x7ffff5db7640 (LWP 1082911) exited]
[Inferior 1 (process 1082907) exited normally]
One thing to notice is the host and GPU threads appearing under
the same inferior. This is a design goal for us, as programmers tend to
think of the threads running on the GPU as part of the same program as
the host threads, so showing them in the same inferior in GDB seems
natural. Also, the host and GPU threads share a global memory space,
which fits the inferior model.
Another thing to notice is the error messages when trying to read
variables or printing a backtrace. This is expected for the moment,
since the AMD GPU compiler produces some DWARF that uses some
non-standard extensions:
https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html
There were already some patches posted by Zoran Zaric earlier to make
GDB support these extensions:
https://inbox.sourceware.org/gdb-patches/20211105113849.118800-1-zoran.zaric@amd.com/
We think it's better to get the basic support for AMD GPU in first,
which will then give a better justification for GDB to support these
extensions.
GPU threads are named `AMDGPU Wave`: a wave is essentially a hardware
thread using the SIMT (single-instruction, multiple-threads) [3]
execution model.
GDB uses the amd-dbgapi library [4], included in the ROCm platform, for
a few things related to AMD GPU threads debugging. Different components
talk to the library, as show on the following diagram:
+---------------------------+ +-------------+ +------------------+
| GDB | amd-dbgapi target | <-> | AMD | | Linux kernel |
| +-------------------+ | Debugger | +--------+ |
| | amdgcn gdbarch | <-> | API | <=> | AMDGPU | |
| +-------------------+ | | | driver | |
| | solib-rocm | <-> | (dbgapi.so) | +--------+---------+
+---------------------------+ +-------------+
- The amd-dbgapi target is a target_ops implementation used to control
execution of GPU threads. While the debugging of host threads works
by using the ptrace / wait Linux kernel interface (as usual), control
of GPU threads is done through a special interface (dubbed `kfd`)
exposed by the `amdgpu` Linux kernel module. GDB doesn't interact
directly with `kfd`, but instead goes through the amd-dbgapi library
(AMD Debugger API on the diagram).
Since it provides execution control, the amd-dbgapi target should
normally be a process_stratum_target, not just a target_ops. More
on that later.
- The amdgcn gdbarch (describing the hardware architecture of the GPU
execution units) offloads some requests to the amd-dbgapi library,
so that knowledge about the various architectures doesn't need to be
duplicated and baked in GDB. This is for example for things like
the list of registers.
- The solib-rocm component is an solib provider that fetches the list of
code objects loaded on the device from the amd-dbgapi library, and
makes GDB read their symbols. This is very similar to other solib
providers that handle shared libraries, except that here the shared
libraries are the pieces of code loaded on the device.
Given that Linux host threads are managed by the linux-nat target, and
the GPU threads are managed by the amd-dbgapi target, having all threads
appear in the same inferior requires the two targets to be in that
inferior's target stack. However, there can only be one
process_stratum_target in a given target stack, since there can be only
one target per slot. To achieve it, we therefore resort the hack^W
solution of placing the amd-dbgapi target in the arch_stratum slot of
the target stack, on top of the linux-nat target. Doing so allows the
amd-dbgapi target to intercept target calls and handle them if they
concern GPU threads, and offload to beneath otherwise. See
amd_dbgapi_target::fetch_registers for a simple example:
void
amd_dbgapi_target::fetch_registers (struct regcache *regcache, int regno)
{
if (!ptid_is_gpu (regcache->ptid ()))
{
beneath ()->fetch_registers (regcache, regno);
return;
}
// handle it
}
ptids of GPU threads are crafted with the following pattern:
(pid, 1, wave id)
Where pid is the inferior's pid and "wave id" is the wave handle handed
to us by the amd-dbgapi library (in practice, a monotonically
incrementing integer). The idea is that on Linux systems, the
combination (pid != 1, lwp == 1) is not possible. lwp == 1 would always
belong to the init process, which would also have pid == 1 (and it's
improbable for the init process to offload work to the GPU and much less
for the user to debug it). We can therefore differentiate GPU and
non-GPU ptids this way. See ptid_is_gpu for more details.
Note that we believe that this scheme could break down in the context of
containers, where the initial process executed in a container has pid 1
(in its own pid namespace). For instance, if you were to execute a ROCm
program in a container, then spawn a GDB in that container and attach to
the process, it will likely not work. This is a known limitation. A
workaround for this is to have a dummy process (like a shell) fork and
execute the program of interest.
The amd-dbgapi target watches native inferiors, and "attaches" to them
using amd_dbgapi_process_attach, which gives it a notifier fd that is
registered in the event loop (see enable_amd_dbgapi). Note that this
isn't the same "attach" as in PTRACE_ATTACH, but being ptrace-attached
is a precondition for amd_dbgapi_process_attach to work. When the
debugged process enables the ROCm runtime, the amd-dbgapi target gets
notified through that fd, and pushes itself on the target stack of the
inferior. The amd-dbgapi target is then able to intercept target_ops
calls. If the debugged process disables the ROCm runtime, the
amd-dbgapi target unpushes itself from the target stack.
This way, the amd-dbgapi target's footprint stays minimal when debugging
a process that doesn't use the AMD ROCm platform, it does not intercept
target calls.
The amd-dbgapi library is found using pkg-config. Since enabling
support for the amdgpu architecture (amdgpu-tdep.c) depends on the
amd-dbgapi library being present, we have the following logic for
the interaction with --target and --enable-targets:
- if the user explicitly asks for amdgcn support with
--target=amdgcn-*-* or --enable-targets=amdgcn-*-*, we probe for
the amd-dbgapi and fail if not found
- if the user uses --enable-targets=all, we probe for amd-dbgapi,
enable amdgcn support if found, disable amdgcn support if not found
- if the user uses --enable-targets=all and --with-amd-dbgapi=yes,
we probe for amd-dbgapi, enable amdgcn if found and fail if not found
- if the user uses --enable-targets=all and --with-amd-dbgapi=no,
we do not probe for amd-dbgapi, disable amdgcn support
- otherwise, amd-dbgapi is not probed for and support for amdgcn is not
enabled
Finally, a simple test is included. It only tests hitting a breakpoint
in device code and resuming execution, pretty much like the example
shown above.
[1] https://docs.amd.com/category/ROCm_v5.4
[2] https://docs.amd.com/bundle/HIP-Programming-Guide-v5.4
[3] https://en.wikipedia.org/wiki/Single_instruction,_multiple_threads
[4] https://docs.amd.com/bundle/ROCDebugger-API-Guide-v5.4
Change-Id: I591edca98b8927b1e49e4b0abe4e304765fed9ee
Co-Authored-By: Zoran Zaric <zoran.zaric@amd.com>
Co-Authored-By: Laurent Morichetti <laurent.morichetti@amd.com>
Co-Authored-By: Tony Tye <Tony.Tye@amd.com>
Co-Authored-By: Lancelot SIX <lancelot.six@amd.com>
Co-Authored-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>
This patch uses the toplevel configure parts for GMP/MPFR for
gdb. The only thing is that gdb now requires MPFR for building.
Before it was a recommended but not required library.
Also this allows building of GMP and MPFR with the toplevel
directory just like how it is done for GCC.
We now error out in the toplevel configure of the version
of GMP and MPFR that is wrong.
OK after GDB 13 branches? Build gdb 3 ways:
with GMP and MPFR in the toplevel (static library used at that point for both)
With only MPFR in the toplevel (GMP distro library used and MPFR built from source)
With neither GMP and MPFR in the toplevel (distro libraries used)
Changes from v1:
* Updated gdb/README and gdb/doc/gdb.texinfo.
* Regenerated using unmodified autoconf-2.69
Thanks,
Andrew Pinski
ChangeLog:
* Makefile.def: Add configure-gdb dependencies
on all-gmp and all-mpfr.
* configure.ac: Split out MPC checking from MPFR.
Require GMP and MPFR if the gdb directory exist.
* Makefile.in: Regenerate.
* configure: Regenerate.
gdb/ChangeLog:
PR bug/28500
* configure.ac: Remove AC_LIB_HAVE_LINKFLAGS
for gmp and mpfr.
Use GMPLIBS and GMPINC which is provided by the
toplevel configure.
* Makefile.in (LIBGMP, LIBMPFR): Remove.
(GMPLIBS, GMPINC): Add definition.
(INTERNAL_CFLAGS_BASE): Add GMPINC.
(CLIBS): Exchange LIBMPFR and LIBGMP
for GMPLIBS.
* target-float.c: Make the code conditional on
HAVE_LIBMPFR unconditional.
* top.c: Remove code checking HAVE_LIBMPFR.
* configure: Regenerate.
* config.in: Regenerate.
* README: Update GMP/MPFR section of the config
options.
* doc/gdb.texinfo: Likewise.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28500
The commit bbaabc767a4293492817a0840819aef2768cce90 introduced an
incorrect thunk for the `configure' script. This patch regenerates
configure by calling autoreconf.
The GDB_AC_CHECK_BFD macro defined in gdb/acinclude.m4 uses the
AC_LINK_IFELSE autoconf macro in order to link a simple program to
check features of libbfd.
If libbfd's link dependencies change, it was necessary to reflect them
either in the definition of the macro, or as a consequence of checking
for them with an autoconf macro resulting in an addition to LIBS.
This patch modifies the definition of the GDB_CHECK_BFD macro in order
to use libtool to perform the test link. This makes it possible to
not have to list dependencies of libbfd (which are indirect to GDB) at
all.
After this patch:
configure:28553: checking for ELF support in BFD
configure:28573: ./libtool --quiet --mode=link gcc -o conftest \
-I../../gdb/../include -I../bfd \
-I../../gdb/../bfd -g -O2 \
-L../bfd -L../libiberty conftest.c -lbfd -liberty \
-lncursesw -lm -ldl >&5
configure:28573: $? = 0
configure:28583: result: yes
Tests performed:
- Configure --with-system-zlib and --without-system-zlib.
- Check link dependencies of installed GDB with both --enable-shared
and --disable-shared.
- Run installed GDB in both cases.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This patch changes the GDB build system in order to use libtool to
link the several built executables. This makes it possible to refer
to libtool libraries (.la files) in CLIBS.
As an application of the above,
BFD now refers to ../libbfd/libbfd.la
OPCODES now refers to ../opcodes/libopcodes.la
LIBBACKTRACE_LIB now refers to ../libbacktrace/libbacktrace.la
LIBCTF now refers to ../libctf/libctf.la
NOTE1: The addition of libtool adds a few new configure-time options
to GDB. Among these, --enable-shared and --disable-shared, which were
previously ignored. Now GDB shall honor these options when linking,
picking up the right version of the referred libtool libraries
automagically.
NOTE2: I have not tested the insight build.
NOTE3: For regenerating configure I used an environment with Autoconf
2.69 and Automake 1.15.1. This should match the previously
used version as announced in the configure script.
NOTE4: Now the installed shared objects libbfd.so, libopcodes.so and
libctf.so are used by gdb if binutils is installed with
--enable-shared.
Testing performed:
- --enable-shared and --disable-shared (the default in binutils) work
as expected: the linked executables link with the archive or shared
libraries transparently.
- Makefile.in modified for EXEEXT = .exe. It installs the binaries
just fine. The installed gdb.exe runs fine.
- Native build regtested in x86_64. No regressions found.
- Cross build for aarch64-linux-gnu built to exercise
program_transform_name and friends. The installed
aarch64-linux-gnu-gdb runs fine.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29372
Approved-By: Simon Marchi <simon.marchi@efficios.com>
gas uses ZSTD_compressStream2 which is only available with libzstd >=
1.4.0, leading to build errors when an older version is installed.
This patch updates the check libzstd presence to check its version is
>= 1.4.0. However, since gas seems to be the only component requiring
such a recent version this may imply that we disable ZSTD support for
all components although some would still benefit from an older
version.
I ran 'autoreconf -f' in all directories containing a configure.ac
file, using vanilla autoconf-2.69 and automake-1.15.1. I noticed
several errors from autoheader in readline, as well as warnings in
intl, but they are unrelated to this patch.
This should fix some of the buildbots.
OK for trunk?
Thanks,
Christophe
