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 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>
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
New in this version:
- Add a PY_MAJOR_VERSION check in configure.ac / AC_TRY_LIBPYTHON. If
the user passes --with-python=python2, this will cause a configure
failure saying that GDB only supports Python 3.
Support for Python 2 is a maintenance burden for any patches touching
Python support. Among others, the differences between Python 2 and 3
string and integer types are subtle. It requires a lot of effort and
thinking to get something that behaves correctly on both. And that's if
the author and reviewer of the patch even remember to test with Python
2.
See this thread for an example:
https://sourceware.org/pipermail/gdb-patches/2021-December/184260.html
So, remove Python 2 support. Update the documentation to state that GDB
can be built against Python 3 (as opposed to Python 2 or 3).
Update all the spots that use:
- sys.version_info
- IS_PY3K
- PY_MAJOR_VERSION
- gdb_py_is_py3k
... to only keep the Python 3 portions and drop the use of some
now-removed compatibility macros.
I did not update the configure script more than just removing the
explicit references to Python 2. We could maybe do more there, like
check the Python version and reject it if that version is not
supported. Otherwise (with this patch), things will only fail at
compile time, so it won't really be clear to the user that they are
trying to use an unsupported Python version. But I'm a bit lost in the
configure code that checks for Python, so I kept that for later.
Change-Id: I75b0f79c148afbe3c07ac664cfa9cade052c0c62
debuginfod is a lightweight web service that indexes ELF/DWARF debugging
resources by build-id and serves them over HTTP.
This patch enables GDB to query debuginfod servers for separate debug
files and source code when it is otherwise not able to find them.
GDB can be built with debuginfod using the --with-debuginfod configure
option.
This requires that libdebuginfod be installed and found at configure time.
debuginfod is packaged with elfutils, starting with version 0.178.
For more information see https://sourceware.org/elfutils/.
Tested on x86_64 Fedora 31.
gdb/ChangeLog:
2020-02-26 Aaron Merey <amerey@redhat.com>
* Makefile.in: Handle optional debuginfod support.
* NEWS: Update.
* README: Add --with-debuginfod summary.
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac: Handle optional debuginfod support.
* debuginfod-support.c: debuginfod helper functions.
* debuginfod-support.h: Ditto.
* doc/gdb.texinfo: Add --with-debuginfod to configure options
summary.
* dwarf2/read.c (dwarf2_get_dwz_file): Query debuginfod servers
when a dwz file cannot be found.
* elfread.c (elf_symfile_read): Query debuginfod servers when a
debuginfo file cannot be found.
* source.c (open_source_file): Query debuginfod servers when a
source file cannot be found.
* top.c (print_gdb_configuration): Include
--{with,without}-debuginfod in the output.
gdb/testsuite/ChangeLog:
2020-02-26 Aaron Merey <amerey@redhat.com>
* gdb.debuginfod: New directory for debuginfod tests.
* gdb.debuginfod/main.c: New test file.
* gdb.debuginfod/fetch_src_and_symbols.exp: New tests.
This patch moves gdbserver to the top level.
This patch is as close to a pure move as possible -- gdbserver still
builds its own variant of gnulib and gdbsupport. Changing this will
be done in a separate patch.
[v2] Note that, per Simon's review comment, this patch changes the
tree so that gdbserver is not built for or1k or score. This makes
sense, because there is apparently not actually a gdbserver port here.
[v3] This version of the patch also splits out some configury into a
new file, gdbserver/configure.host, so that the top-level configure
script can simply rely on it in order to decide whether gdbserver
should be built.
[v4] This version adds documentation and removes some unnecessary
top-level dependencies.
[v5] Update docs to mention "make all-gdbserver" and change how
top-level configure decides whether to build gdbserver, switching to a
single, shared script.
Tested by the buildbot.
ChangeLog
2020-02-07 Tom Tromey <tom@tromey.com>
Pedro Alves <palves@redhat.com>
* src-release.sh (GDB_SUPPORT_DIRS): Add gdbserver.
* gdbserver: New directory, moved from gdb/gdbserver.
* configure.ac (host_tools): Add gdbserver.
Only build gdbserver on certain systems.
* Makefile.in, configure: Rebuild.
* Makefile.def (host_modules, dependencies): Add gdbserver.
* MAINTAINERS: Add gdbserver.
gdb/ChangeLog
2020-02-07 Tom Tromey <tom@tromey.com>
* README: Update gdbserver documentation.
* gdbserver: Move to top level.
* configure.tgt (build_gdbserver): Remove.
* configure.ac: Remove --enable-gdbserver.
* configure: Rebuild.
* Makefile.in (distclean): Don't mention gdbserver.
Change-Id: I826b7565b54604711dc7a11edea0499cd51ff39e
Adds descriptions for some recent-ish configure options to README.
Also updates the minimum Python version per commit
6c28e44a35.
2019-11-14 Christian Biesinger <cbiesinger@google.com>
* README (`configure' options): Update.
Change-Id: I8ce8ca6935afbd130295e143802c585cf1e735f9
This is a follow-up of:
https://sourceware.org/ml/gdb-patches/2018-08/msg00347.html
Instead of going throttle and always enabling our selftests (even in
non-development builds), this patch is a bit more conservative and
introduces a configure option ("--enable-unit-tests") that allows the
user to choose whether she wants unit tests in the build or not. Note
that the current behaviour is retained: if no option is provided, GDB
will have selftests included in a development build, and will *not*
have selftests included in a non-development build.
The rationale for having this option is still the same: due to the
many racy testcases and random failures we see when running the GDB
testsuite, it is unfortunately not possible to perform a full test
when one is building a downstream package. As the Fedora GDB
maintainer and one of the Debian GDB uploaders, I feel like this
situation could be improved by, at least, executing our selftests
after the package has been built.
This patch introduces no regressions to our build.
OK?
gdb/ChangeLog:
2018-10-10 Sergio Durigan Junior <sergiodj@redhat.com>
Simon Marchi <simark@simark.ca>
* README (`configure' options): Add documentation for new
"--enable-unit-tests" option.
* acinclude.m4: Include "selftest.m4".
* configure: Regenerate.
* configure.ac: Use "GDB_AC_SELFTEST".
* maint.c (maintenance_selftest): Update message informing
that selftests have been disabled.
(maintenance_info_selftests): Likewise.
* selftest.m4: New file.
gdb/gdbserver/ChangeLog:
2018-10-10 Sergio Durigan Junior <sergiodj@redhat.com>
Simon Marchi <simark@simark.ca>
* acinclude.m4: Include "../selftest.m4".
* configure: Regenerate.
* configure.ac: Use "GDB_AC_SELFTEST".
* configure.srv: Use "$enable_unittests" instead of
"$development" when checking whether unit tests have been
enabled.
* server.c (captured_main): Update message informing that
selftests have been disabled.
gdb/testsuite/ChangeLog:
2018-10-10 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.gdb/unittest.exp: Update expected message informing that
selftests have been disabled.
* gdb.server/unittest.exp: Likewise.
squash! Add parameter to allow enabling/disabling selftests via configure
This adds --enable-ubsan to gdb's configure. By default it is enabled
in development mode, and disabled otherwise. This passes both
-fsanitize=undefined and -fno-sanitize-recover=undefined to
compilations, so that undefined behavior violations will be sure to
cause test failures.
gdb/ChangeLog
2018-10-03 Tom Tromey <tom@tromey.com>
* README: Mention --enable-ubsan.
* NEWS: Mention --enable-ubsan.
* acinclude.m4: Include sanitize.m4.
* configure: Rebuild.
* configure.ac: Call AM_GDB_UBSAN.
* sanitize.m4: New file.
gdb/doc/ChangeLog
2018-10-03 Tom Tromey <tom@tromey.com>
* gdb.texinfo (Configure Options): Document --enable-ubsan.
I realized that while I'd updated the README, I didn't update
gdb.texinfo to document the options to configure.
This patch copies the text from README into gdb.texinfo, adding
Texinfo markup.
gdb/ChangeLog
2018-10-01 Tom Tromey <tom@tromey.com>
* README: Minor change.
gdb/doc/ChangeLog
2018-10-01 Tom Tromey <tom@tromey.com>
* gdb.texinfo (Configure Options): Document configure options.
I accidentally left some stray text in gdb/README.
This removes it. I'm checking this in as obvious.
gdb/ChangeLog
2018-09-29 Tom Tromey <tom@tromey.com>
* README: Remove some leftover text.
gdb's README and configure instructions in the manual are quite out of
date. They mention options that haven't existed for many years, among
other things.
This patch attempts to modernize the instructions somewhat. It is not
exhaustive, just an improvement -- more could be done. Perhaps even a
couple of the nodes should simply be removed and replaced by
references to the Autoconf manual.
The README file seems to have been generated from the Texinfo at some
point in the past. I did not continue this, but instead edited it
separately.
gdb/ChangeLog
2018-09-29 Tom Tromey <tom@tromey.com>
* PROBLEMS: Rewrite.
* README: Update.
gdb/doc/ChangeLog
2018-09-29 Tom Tromey <tom@tromey.com>
* gdb.texinfo (Requirements): Mention C++, GNU make.
(Requirements): Sort the table. Add more libraries.
(Running Configure): Remove obsolete text.
(Separate Objdir): Likewise.
(Configure Options): Likewise.
This second patch introduces mfpr_float_ops, an new implementation
of target_float_ops. This implements precise emulation of target
floating-point formats using the MPFR library. This is then used
to perform operations on types that do not match any host type.
Note that use of MPFR is still not required. The patch adds
a configure option --with-mpfr similar to --with-expat. If use of
MPFR is disabled via the option or MPFR is not available, code will
fall back to current behavior. This means that operations on types
that do not match any host type will be implemented on the host
long double type instead.
A new test case verifies that we can correctly print the largest
__float128 value now.
gdb/ChangeLog:
2017-11-22 Ulrich Weigand <uweigand@de.ibm.com>
* NEWS: Document use of GNU MPFR.
* README: Likewise.
* Makefile.in (LIBMPFR): Add define.
(CLIBS): Add $(LIBMPFR).
* configure.ac: Add --with-mpfr configure option.
* configure: Regenerate.
* config.in: Regenerate.
* target-float.c [HAVE_LIBMPFR]: Include <mpfr.h>.
(class mpfr_float_ops): New type.
(mpfr_float_ops::from_target): Two new overloaded functions.
(mpfr_float_ops::to_target): Likewise.
(mpfr_float_ops::to_string): New function.
(mpfr_float_ops::from_string): Likewise.
(mpfr_float_ops::to_longest): Likewise.
(mpfr_float_ops::from_longest): Likewise.
(mpfr_float_ops::from_ulongest): Likewise.
(mpfr_float_ops::to_host_double): Likewise.
(mpfr_float_ops::from_host_double): Likewise.
(mpfr_float_ops::convert): Likewise.
(mpfr_float_ops::binop): Likewise.
(mpfr_float_ops::compare): Likewise.
(get_target_float_ops): Use mpfr_float_ops if available.
gdb/doc/ChangeLog:
2017-11-22 Ulrich Weigand <uweigand@de.ibm.com>
* gdb.texinfo (Requirements): Document use of GNU MPFR.
gdb/testsuite/ChangeLog:
2017-11-22 Ulrich Weigand <uweigand@de.ibm.com>
* gdb.base/float128.c (large128): New variable.
* gdb.base/float128.exp: Add test to print largest __float128 value.
* libunwind-frame.c: Rename to ...
* ia64-libunwind-tdep.c: ... here.
* libunwind-frame.h: Rename to ...
* ia64-libunwind-tdep.h: ... here.
* Makefile.in (HFILES_NO_SRCDIR): Rename libunwind-frame.h to
ia64-libunwind-tdep.h.
(ALLDEPFILES): Rename libunwind-frame.c to ia64-libunwind-tdep.c.
* README (--with-libunwind): Rename to ...
(--with-libunwind-ia64): ... here, note it is ia64 specific now.
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac: New option --with-libunwind-ia64, make the
AS_HELP_STRING ia64 specific. Deprecate option --with-libunwind.
Remove AC_DEFINE for HAVE_LIBUNWIND.
* ia64-libunwind-tdep.c: Make the file top comment ia64 specific.
Rename libunwind-frame.h #include to ia64-libunwind-tdep.h.
Rename libunwind-frame in the general comment.
* ia64-libunwind-tdep.h: Make the file top comment ia64 specific.
Rename symbol LIBUNWIND_FRAME_H to IA64_TDEP_LIBUNWIND_FRAME_H.
Move forward declarations inside #ifndef. Rename libunwind-frame in
the general comment.
* ia64-tdep.c: Rename libunwind-frame.h #include to
ia64-libunwind-tdep.h.
(ia64_gdb2uw_regnum, ia64_uw2gdb_regnum, ia64_is_fpreg)
(ia64_libunwind_descr): Rename libunwind-frame to
ia64-libunwind-tdep in these function comments.
* ia64-tdep.h: Rename libunwind-frame.h #include to
ia64-libunwind-tdep.h.
* ia64-vms-tdep.c (ia64_vms_libunwind_descr): Rename libunwind-frame to
ia64-libunwind-tdep in that data comment.
* README: Mention parallel check.
gdb/testsuite
* dg-extract-results.sh: New file.
* Makefile.in (FORCE_PARALLEL): New variable.
(CHECK_TARGET): New conditional variable.
(check): Use CHECK_TARGET.
(DO_RUNTEST): New variable.
(check-single): New target.
(TEST_DIRS): New variable.
(TEST_TARGETS): Likewise.
(check-parallel): New target.
(check-gdb.%): New pattern.
(BASE1_FILES): New variable.
(BASE2_FILES): Likewise.
(check-gdb.base%): New pattern.
(%/.dir): New pattern.
* configure: Rebuild.
* aclocal.m4 (AM_CONDITIONAL): New defun.
* configure.ac: Check whether user is using GNU make.
(GMAKE): New conditional.
