gdb: add gdbarch method to get execution context from core file
The above commit improves GDB's ability to display inferior arguments
when opening a core file, however, if an argument includes white
space, then this is not displayed as well as it should be. For
example:
(gdb) core-file /tmp/corefile-exec-context.2.core
[New LWP 4069711]
Reading symbols from /tmp/corefile-exec-context...
Core was generated by `/tmp/corefile-exec-context aaaaa bbbbb ccccc ddddd e e e e e'.
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 return ret;
(gdb) show args
Argument list to give program being debugged when it is started is "aaaaa bbbbb ccccc ddddd e\ e\ e\ e\ e".
(gdb)
Notice the 'Core was generated by ...' line. In this case it is not
clear if the "e e e e e" is a single argument containing white space,
or 5 single arguments.
But when we 'show args' it is immediately clear that this is a single
argument, as the white space is now escaped.
This problem was caused by the above commit building the argument
string itself, and failing to consider white space escaping.
This commit changes things around, first we place the arguments into
the inferior, then, to print the 'Core was generated by ...' line, we
ask the inferior for the argument string. In this way the quoting is
handled just as it is for 'show args'. The initial output is now:
(gdb) core-file /tmp/corefile-exec-context.2.core
[New LWP 4069711]
Reading symbols from /tmp/corefile-exec-context...
Core was generated by `/tmp/corefile-exec-context aaaaa bbbbb ccccc ddddd e\ e\ e\ e\ e'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f4f007af625 in raise () from /lib64/libc.so.6
(gdb)
Much better. The existing test is extended to cover this case.
Reviewed-By: Guinevere Larsen <guinevere@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
Commit 3470a0e144df6c01f8479fa649f43aa907936e7e inadvertently broke
the build on MIPS because it's passing a non-existent "pid" argument
to "proc->for_each_thread". This commit fixes the problem by removing
the argument from the call.
Signed-off-by: Sergio Durigan Junior <sergiodj@sergiodj.net> Approved-By: Simon Marchi <simon.marchi@efficios.com>
In that commit, linetables were made independent from the objfile, which
requires objfile->section_offsets to be initialized. However, section_offsets
were never initialized in objfiles generated by GDB's JIT Interface
with custom jit-readers, leading to GDB crashes when stepping into JITed code
blocks with the following command already executed:
jit-reader-load libmygdbjitreader.so
This patch fixes the issue by initializing the minimum section_offsets required
for linetable parsing procedures.
A minimal test is included. The test sets up some very simple line
table information, which is enough to trigger the bug. However, the
line table information is crafted such that none of the line table
entries will end up being displayed in GDB's output when the test is
run, as such, none of the expected output actually changes.
It might be nice in the future to extend some of the jit tests to
actually test hitting line table entries added via the jit reader.
Tom Tromey [Mon, 6 Jan 2025 14:45:33 +0000 (07:45 -0700)]
Handle case where DAP line can be None
A comment in bugzilla pointed out a bug in my earlier patch to handle
the DAP "linesStartAt1" setting. In particular, in the backtrace
code, "line" can be None, which would lead to an exception from
export_line.
Tom Tromey [Mon, 6 Jan 2025 20:34:47 +0000 (13:34 -0700)]
Fix crash in DWARF indexer
Iain pointed out a crash in the DWARF indexer when run on a certain D
program. The DWARF in this case has a nameless enum class; this
causes an assertion failure.
This patch arranges to simply ignore such types. The fact that an
enum class is nameless in this case appears to be a compiler bug.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32518 Approved-By: Tom de Vries <tdevries@suse.de>
(cherry picked from commit 66903f1d66a2648e82250a427a791286e4ed4735)
Rainer Orth [Mon, 6 Jan 2025 15:24:14 +0000 (16:24 +0100)]
Fix procfs.c compilation
procfs.c compilation is currently broken on Solaris:
/vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c: In member function ‘virtual ptid_t procfs_target::wait(ptid_t, target_waitstatus*, target_wait_flags)’:
/vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c:2067:34: error: ‘wait’ is not a member of ‘gdb’; did you mean ‘wait’?
2067 | wait_retval = gdb::wait (&wstat);
| ^~~~
In file included from ../gnulib/import/sys/wait.h:28,
from /usr/include/stdlib.h:16,
from /usr/gcc/14/include/c++/14.2.0/cstdlib:79,
from /vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/../gdbsupport/common-defs.h:99,
from /vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/defs.h:26,
from <command-line>:
/usr/include/sys/wait.h:85:14: note: ‘wait’ declared here
85 | extern pid_t wait(int *);
| ^~~~
/vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c:2154:41: error: ‘wait’ is not a member of ‘gdb’; did you mean ‘wait’?
2154 | int temp = gdb::wait (&wstat);
| ^~~~
/usr/include/sys/wait.h:85:14: note: ‘wait’ declared here
85 | extern pid_t wait(int *);
| ^~~~
/vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c: In function ‘void unconditionally_kill_inferior(procinfo*)’:
/vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c:2566:12: error: ‘wait’ is not a member of ‘gdb’; did you mean ‘wait’?
2566 | gdb::wait (NULL);
| ^~~~
/usr/include/sys/wait.h:85:14: note: ‘wait’ declared here
85 | extern pid_t wait(int *);
| ^~~~
Tom de Vries [Mon, 6 Jan 2025 09:04:22 +0000 (10:04 +0100)]
[gdb/build] Use const_cast in fd_copy
Recent commit 6ab5d62ebc5 ("[gdb] Fix compilation error in event-top.c") did:
...
fd_copy (fd_set *dst, const fd_set *src, int n)
{
FD_ZERO (dst);
for (int i = 0; i < n; ++i)
- if (FD_ISSET (i, src))
+ if (FD_ISSET (i, (fd_set *)src))
...
but according to [1] only const_cast may be used to cast away constness.
Running selftest help_doc_invariants.
help doc broken invariant: command 'signal-event' help doc has over-long line
Self test failed: self-test failed at unittests/command-def-selftests.c:121
The reason is that doc string of 'signal-event' doesn't have
newlines at end of its line. Fix by adding newlines.
Alan Modra [Wed, 1 Jan 2025 12:01:50 +0000 (22:31 +1030)]
PR 32507, PRIx64 in error messages on 32-bit mingw
People, including me, had forgotten that the bfd_error_handler just
handled standard printf format strings, not MSC %I64 and suchlike.
Using PRIx64 and similar in errors does not work if the host compiler
headers define those formats as the Microsoft %I64 variety. (We
handled %ll OK, editing it to %I64 on such hosts.)
PR 32507
* bfd.c (_bfd_doprnt, _bfd_doprnt_scan): Handle %I64 and %I32
in input strings if the host defines PRId64 as "I64d".
Edit %ll to %I64 on detecting PRId64 as "I64d" rather than on
a preprocessor define.
Jan Beulich [Fri, 27 Dec 2024 10:37:05 +0000 (11:37 +0100)]
ld/testsuite: replace aarch64 uses of load_lib
Using $srcdir/$subdir directly doesn't work, at least not with expect
5.45, dejagnu 1.6, and an out-of-tree build (I assume it's the latter
aspect which is crucial here). Make use of load_file instead.
Xi Ruoyao [Wed, 25 Dec 2024 04:41:45 +0000 (12:41 +0800)]
LoongArch: Reword message for unresolvable relocs
For PDE, "recompiling with -fPIE" just makes no sense.
For PIE, "recompiling with -fPIE" makes sense for unresolvable absolute
relocs, but not unresolveable PC-relative relocs: if the reloc is
already PC-relative, the problem is not the reloc is PC-relative or
absolute, but the reloc is not applicable for external symbols.
If we hit an unresolvable reloc in PDE or an unresolvable PC-relative
reloc in PIE, it means the programmer has somehow wrongly instructed the
compiler to treat external symbols as local symbols. A misuse of
-mdirect-extern-access can cause the issue, so we can suggest
-mno-direct-extern-access. And in all cases (DSO/PIE/PDE) a mismatching
symbol visibility can also cause the issue, so we should also suggest to
check the visibility.
Xi Ruoyao [Wed, 25 Dec 2024 04:41:44 +0000 (12:41 +0800)]
LoongArch: Allow R_LARCH_PCALA_HI20 or R_LARCH_PCREL20_S2 against undefined weak symbols for static PIE
In a static PIE, undefined weak symbols should be just resolved to
runtime address 0, like those symbols with non-default visibility. This
was silently broken in all prior Binutils releases with "-static-pie
-mdirect-extern-access":
$ cat t.c
int x (void) __attribute__ ((weak));
int
main (void)
{
__builtin_printf("%p\n", x);
}
$ gcc t.c -static-pie -mdirect-extern-access
$ ./a.out
0x7ffff1d64000
Since commit 4cb77761d687 ("LoongArch: Check PC-relative relocations for
shared libraries), the situation has been improved: the linker errors
out instead of silently producing a wrong output file.
But logically, using -mdirect-extern-access for a static PIE perfectly
makes sense, and we should not prevent that even if the programmer uses
weak symbols. Linux kernel is such an example, and Linux < 6.10 now
fails to build with Binutils trunk. (The silent breakage with prior
Binutils releases was "benign" due to some blind luck.)
While since the 6.10 release Linux has removed those potentially
undefined weak symbols (due to performance issue), we still should
support weak symbols in -mdirect-extern-access -static-pie and unbreak
building old kernels.
Xi Ruoyao [Wed, 25 Dec 2024 04:41:43 +0000 (12:41 +0800)]
LoongArch: Fix resolution of undefined weak hidden/protected symbols
An undefined weak hidden/protect symbol should be resolved to runtime
address 0, but we were actually resolving it to link-time address 0. So
in PIE or DSO the runtime address would be incorrect.
Fix the issue by rewriting pcalau12i to lu12i.w, and pcaddi to addi.w.
The latter does not always work because the immediate field of addi.w is
narrower, report an error in the case the addend is too large.
Alan Modra [Wed, 25 Dec 2024 08:47:24 +0000 (19:17 +1030)]
buffer overflow in gas/app.c
This testcase:
.irp x x x "
.end #
.endr
manages to access lex[EOF].
xxx: Warning: end of file in string; '"' inserted
xxx:1: Warning: missing closing `"'
gas/app.c:844:16: runtime error: index -1 out of bounds for type 'char [256]
Following that there is a buffer overflow.
Stop this happening, and in other similar places, by checking for EOF.
Andrew Burgess [Fri, 15 Dec 2023 13:03:26 +0000 (13:03 +0000)]
gdb/testsuite: add some xfail in gdb.base/startup-with-shell.exp
There are two tests that fail in gdb.base/startup-with-shell.exp when
using the native-extended-remote board. I plan to fix these issues,
and I've posted a series that does just that:
Andrew Burgess [Mon, 21 Oct 2024 15:41:54 +0000 (16:41 +0100)]
gdb/freebsd: port core file context parsing to FreeBSD
This commit implements the gdbarch_core_parse_exec_context method for
FreeBSD.
This is much simpler than for Linux. On FreeBSD, at least the
version (13.x) that I have installer, there are additional entries in
the auxv vector that point directly to the argument and environment
vectors, this makes it trivial to find this information.
If these extra auxv entries are not available on earlier FreeBSD, then
that's fine. The fallback behaviour will be for GDB to act as it
always has up to this point, you'll just not get the extra
functionality.
Other differences compared to Linux are that FreeBSD has
AT_FREEBSD_EXECPATH instead of AT_EXECFN, the AT_FREEBSD_EXECPATH is
the full path to the executable. On Linux AT_EXECFN is the command
the user typed, so this can be a relative path.
This difference is handy as on FreeBSD we don't parse the mapped files
from the core file (are they even available?). So having the EXECPATH
means we can use that as the absolute path to the executable.
However, if the user ran a symlink then AT_FREEBSD_EXECPATH will be
the absolute path to the symlink, not to the underlying file. This is
probably a good thing, but it does mean there is one case we test on
Linux that fails on FreeBSD.
On Linux if we create a symlink to an executable, then run the symlink
and generate a corefile. Now delete the symlink and load the core
file. On Linux GDB will still find (and open) the original
executable. This is because we use the mapped file information to
find the absolute path to the executable, and the mapped file
information only stores the real file names, not symlink names.
This is a total edge case, I only added the deleted symlink test
originally because I could see that this would work on Linux. Though
it is neat that Linux finds this, I don't feel too bad that this fails
on FreeBSD.
Other than this, everything seems to work on x86-64 FreeBSD (13.4)
which is all I have setup right now. I don't see why other
architectures wouldn't work too, but I haven't tested them.
Andrew Burgess [Thu, 2 May 2024 14:37:42 +0000 (15:37 +0100)]
gdb: improve GDB's ability to auto-load the exec for a core file
GDB already has a limited mechanism for auto-loading the executable
corresponding to a core file, this can be found in the function
locate_exec_from_corefile_build_id in corelow.c.
However, this approach uses the build-id of the core file to look in
either the debug directory (for a symlink back to the executable) or
by asking debuginfod. This is great, and works fine if the core file
is a "system" binary, but often, when I'm debugging a core file, it's
part of my development cycle, so there's no build-id symlink in the
debug directory, and debuginfod doesn't know about the binary either,
so GDB can't auto load the executable....
... but the executable is right there!
This commit builds on the earlier commits in this series to make GDB
smarter.
On GNU/Linux, when we parse the execution context from the core
file (see linux-tdep.c), we already grab the command pointed to by
AT_EXECFN. If this is an absolute path then GDB can use this to
locate the executable, a build-id check ensures we've found the
correct file. With this small change GDB suddenly becomes a lot
better at auto-loading the executable for a core file.
But we can do better! Often the AT_EXECFN is not an absolute path.
If it is a relative path then we check for this path relative to the
core file. This helps if a user does something like:
In this case the core file in the current directory will have an
AT_EXECFN value of './build/bin/some_prog', so if we look for that
path relative to the location of the core file this might result in a
hit, again, a build-id check ensures we found the right file.
But we can do better still! What if the user moves the core file? Or
the user is using some tool to manage core files (e.g. the systemd
core file management tool), and the user downloads the core file to a
location from which the relative path no longer works?
Well in this case we can make use of the core file's mapped file
information (the NT_FILE note). The executable will be included in
the mapped file list, and the path within the mapped file list will be
an absolute path. We can search for mapped file information based on
an address within the mapped file, and the auxv vector happens to
include an AT_ENTRY value, which is the entry address in the main
executable. If we look up the mapped file containing this address
we'll have the absolute path to the main executable, a build-id check
ensures this really is the file we're looking for.
It might be tempting to jump straight to the third approach, however,
there is one small downside to the third approach: if the executable
is a symlink then the AT_EXECFN string will be the name of the
symlink, that is, the thing the user asked to run. The mapped file
entry will be the name of the actual file, i.e. the symlink target.
When we auto-load the executable based on the third approach, the file
loaded might have a different name to that which the user expects,
though the build-id check (almost) guarantees that we've loaded the
correct binary.
But there's one more thing we can check for!
If the user has placed the core file and the executable into a
directory together, for example, as might happen with a bug report,
then neither the absolute path check, nor the relative patch check
will find the executable. So GDB will also look for a file with the
right name in the same directory as the core file. Again, a build-id
check is performed to ensure we find the correct file.
Of course, it's still possible that GDB is unable to find the
executable using any of these approaches. In this case, nothing
changes, GDB will check in the debug info directory for a build-id
based link back to the executable, and if that fails, GDB will ask
debuginfod for the executable. If this all fails, then, as usual, the
user is able to load the correct executable with the 'file' command,
but hopefully, this should be needed far less from now on.
Andrew Burgess [Thu, 24 Oct 2024 21:04:10 +0000 (22:04 +0100)]
gdb/testsuite: make some of the core file / build-id tests harder
We have a few tests that load core files, which depend on GDB not
auto-loading the executable that matches the core file. One of these
tests (corefile-buildid.exp) exercises GDB's ability to load the
executable via the build-id links in the debug directory, while the
other two tests are just written assuming that GDB hasn't auto-loaded
the executable.
In the next commit, GDB is going to get better at finding the
executable for a core file, and as a consequence these tests could
start to fail if the testsuite is being run using a compiler that adds
build-ids by default, and is on a target (currently only Linux) with
the improved executable auto-loading.
To avoid these test failures, this commit updates some of the tests.
coredump-filter.exp and corefile.exp are updated to unload the
executable should it be auto-loaded. This means that the following
output from GDB will match the expected patterns. If the executable
wasn't auto-loaded then the new step to unload is harmless.
The corefile-buildid.exp test needed some more significant changes.
For this test it is important that the executable be moved aside so
that GDB can't locate it, but we do still need the executable around
somewhere, so that the debug directory can link to it. The point of
the test is that the executable _should_ be auto-loaded, but using the
debug directory, not using GDB's context parsing logic.
While looking at this test I noticed two additional problems, first we
were creating the core file more times than we needed. We only need
to create one core file for each test binary (total two), while we
previously created one core file for each style of debug info
directory (total four). The extra core files should be identical, and
were just overwriting each other, harmless, but still pointless work.
The other problem is that after running an earlier test we modified
the test binary in order to run a later test. This means it's not
possible to manually re-run the first test as the binary for that test
is destroyed.
As part of the rewrite in this commit I've addressed these issues.
This test does change many of the test names, but there should be no
real changes in what is being tested after this commit. However, when
the next commit is added, and GDB gets better at auto-loading the
executable for a core file, these tests should still be testing what
is expected.
Andrew Burgess [Sat, 8 Jun 2024 10:06:02 +0000 (11:06 +0100)]
gdb: parse and set the inferior environment from core files
Extend the core file context parsing mechanism added in the previous
commit to also store the environment parsed from the core file.
This environment can then be injected into the inferior object.
The benefit of this is that when examining a core file in GDB, the
'show environment' command will now show the environment extracted
from a core file.
Consider this example:
$ env -i GDB_TEST_VAR=FOO ./gen-core
Segmentation fault (core dumped)
$ gdb -c ./core.1669829
...
[New LWP 1669829]
Core was generated by `./gen-core'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000401111 in ?? ()
(gdb) show environment
GDB_TEST_VAR=foo
(gdb)
Andrew Burgess [Thu, 25 Apr 2024 08:36:43 +0000 (09:36 +0100)]
gdb: add gdbarch method to get execution context from core file
Add a new gdbarch method which can read the execution context from a
core file. An execution context, for this commit, means the filename
of the executable used to generate the core file and the arguments
passed to the executable.
In later commits this will be extended further to include the
environment in which the executable was run, but this commit is
already pretty big, so I've split that part out into a later commit.
Initially this new gdbarch method is only implemented for Linux
targets, but a later commit will add FreeBSD support too.
Currently when GDB opens a core file, GDB reports the command and
arguments used to generate the core file. For example:
(gdb) core-file ./core.521524
[New LWP 521524]
Core was generated by `./gen-core abc def'.
However, this information comes from the psinfo structure in the core
file, and this struct only allows 80 characters for the command and
arguments combined. If the command and arguments exceed this then
they are truncated.
Additionally, neither the executable nor the arguments are quoted in
the psinfo structure, so if, for example, the executable was named
'aaa bbb' (i.e. contains white space) and was run with the arguments
'ccc' and 'ddd', then when this core file was opened by GDB we'd see:
(gdb) core-file ./core.521524
[New LWP 521524]
Core was generated by `./aaa bbb ccc ddd'.
It is impossible to know if 'bbb' is part of the executable filename,
or another argument.
However, the kernel places the executable command onto the user stack,
this is pointed to by the AT_EXECFN entry in the auxv vector.
Additionally, the inferior arguments are all available on the user
stack. The new gdbarch method added in this commit extracts this
information from the user stack and allows GDB to access it.
The information on the stack is writable by the user, so a user
application can start up, edit the arguments, override the AT_EXECFN
string, and then dump core. In this case GDB will report incorrect
information, however, it is worth noting that the psinfo structure is
also filled (by the kernel) by just copying information from the user
stack, so, if the user edits the on stack arguments, the values
reported in psinfo will change, so the new approach is no worse than
what we currently have.
The benefit of this approach is that GDB gets to report the full
executable name and all the arguments without the 80 character limit,
and GDB is aware which parts are the executable name, and which parts
are arguments, so we can, for example, style the executable name.
Another benefit is that, now we know all the arguments, we can poke
these into the inferior object. This means that after loading a core
file a user can 'show args' to see the arguments used. A user could
even transition from core file debugging to live inferior debugging
using, e.g. 'run', and GDB would restart the inferior with the correct
arguments.
Now the downside: finding the AT_EXECFN string is easy, the auxv entry
points directly too it. However, finding the arguments is a little
trickier. There's currently no easy way to get a direct pointer to
the arguments. Instead, I've got a heuristic which I believe should
find the arguments in most cases. The algorithm is laid out in
linux-tdep.c, I'll not repeat it here, but it's basically a search of
the user stack, starting from AT_EXECFN.
If the new heuristic fails then GDB just falls back to the old
approach, asking bfd to read the psinfo structure for us, which gives
the old 80 character limited answer.
For testing, I've run this series on (all GNU/Linux) x86-64. s390,
ppc64le, and the new test passes in each case. I've done some very
basic testing on ARM which does things a little different than the
other architectures mentioned, see ARM specific notes in
linux_corefile_parse_exec_context_1 for details.
Alan Modra [Tue, 24 Dec 2024 00:58:46 +0000 (11:28 +1030)]
arc: add_to_decodelist
Given objdump -Mcpu=archs -D or similar, add_to_decodelist adds three
entries to decodelist for each instruction disassembled. That can
waste a lot of cpu when the list grows large. What's more,
decodelist is static and nothing clears the list. So the list
persists from one file to the next if objdump is disassembling
multiple files in one invocation. Wrong disassembly might result.
To fix this problem, I've moved decodelist to the arc private_data and
made it an array. I believe that init_disassemble_data will be
called, clearing private_data, for each file disassembled. That's
certainly true for objdump, and if I can see my way around gdb
constructors, it's also true for gdb. I don't think there is a
possibility of info.disassembler_options changing unless there is
first a call to init_disassebled_data. That means all of the option
parsing and bfd mach and e_flags decoding need only be done when
initialising the arc private_data.
Alan Modra [Sun, 22 Dec 2024 23:56:02 +0000 (10:26 +1030)]
PR 32324, Stripping BOLT'ed binaries leads to unwanted behaviour
This patch corrects layout for a PT_LOAD header that doesn't include
the ELF file header but does contain PHDRs and sections requiring
alignment. The required alignment (which was missing) is placed
before the PHDRs.
Haochen Jiang [Mon, 23 Dec 2024 03:32:03 +0000 (11:32 +0800)]
Support Intel AVX10.2 minmax, vector copy and compare instructions
In this patch, we will support AVX10.2 minmax, vector copy and compare
instructions. This will finish the new instruction form support for
AVX10.2. Most of them are new instructions forms except for vmovd
and vmovw, which are extended usage from the old ones.
Carlos Galvez [Sat, 21 Dec 2024 21:25:40 +0000 (22:25 +0100)]
Fix -Wenum-constexpr-conversion in enum-flags.h
This fixes PR 31331:
https://sourceware.org/bugzilla/show_bug.cgi?id=31331
Currently, enum-flags.h is suppressing the warning
-Wenum-constexpr-conversion coming from recent versions of Clang.
This warning is intended to be made a compiler error
(non-downgradeable) in future versions of Clang:
https://github.com/llvm/llvm-project/issues/59036
The rationale is that casting a value of an integral type into an
enumeration is Undefined Behavior if the value does not fit in the
range of values of the enum:
https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1766
Undefined Behavior is not allowed in constant expressions, leading to
an ill-formed program.
In this case, in enum-flags.h, we are casting the value -1 to an enum
of a positive range only, which is UB as per the Standard and thus not
allowed in a constexpr context.
The purpose of doing this instead of using std::underlying_type is
because, for C-style enums, std::underlying_type typically returns
"unsigned int". However, when operating with it arithmetically, the
enum is promoted to *signed* int, which is what we want to avoid.
This patch solves this issue as follows:
* Use std::underlying_type and remove the custom enum_underlying_type.
* Ensure that operator~ is called always on an unsigned integer. We do
this by casting the input enum into std::size_t, which can fit any
unsigned integer. We have the guarantee that the cast is safe,
because we have checked that the underlying type is unsigned. If the
enum had negative values, the underlying type would be signed.
This solves the issue with C-style enums, but also solves a hidden
issue: enums with underlying type of std::uint8_t or std::uint16_t are
*also* promoted to signed int. Now they are all explicitly casted
to the largest unsigned int type and operator~ is safe to use.
* There is one more thing that needs fix. Currently, operator~ is
implemented as follows:
return (enum_type) ~underlying(e);
After applying ~underlying(e), the result is a very large value,
which we then cast to "enum_type". This cast is Undefined Behavior
if the large value does not fit in the range of the enum. For
C++ enums (scoped and/or with explicit underlying type), the range
of the enum is the entire range of the underlying type, so the cast
is safe. However, for C-style enums, the range is the smallest
bit-field that can hold all the values of the enumeration. So the
range is a lot smaller and casting a large value to the enum would
invoke Undefined Behavior.
To solve this problem, we create a new trait
EnumHasFixedUnderlyingType, to ensure operator~ may only be called
on C++-style enums. This behavior is roughly the same as what we
had on trunk, but relying on different properties of the enums.
* Once this is implemented, the following tests fail to compile:
CHECK_VALID (true, int, true ? EF () : EF2 ())
This is because it expects the enums to be promoted to signed int,
instead of unsigned int (which is the true underlying type).
I propose to remove these tests altogether, because:
- The comment nearby say they are not very important.
- Comparing 2 enums of different type like that is strange, relies
on integer promotions and thus hurts readability. As per comments
in the related PR, we likely don't want this type of code in gdb
code anyway, so there's no point in testing it.
- Most importantly, this type of comparison will be ill-formed in
C++26 for regular enums, so enum_flags does not need to emulate
that.
Since this is the only place where the warning was suppressed, remove
also the corresponding macro in include/diagnostics.h.
The change has been tested by running the entire gdb test suite
(make check) and comparing the results (testsuite/gdb.sum) against
trunk. No noticeable differences have been observed.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31331 Tested-by: Keith Seitz <keiths@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
Keith Seitz [Fri, 20 Dec 2024 20:46:11 +0000 (12:46 -0800)]
Add gstack script
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>
Tom Tromey [Fri, 20 Dec 2024 20:36:37 +0000 (13:36 -0700)]
Minor cleanups in rust-lang.c
This patch is a few minor cleanups to rust-lang.c: renaming a
badly-named local variable, moving a couple of declarations into 'for'
headers, and using 'bool' in one spot.
Richard Earnshaw [Fri, 20 Dec 2024 18:28:05 +0000 (18:28 +0000)]
arm: fix incorrect assembly of stm{,ia} as push [PR32363]
PR/32363.
Gas was incorrectly translating
stm sp!, {regs}
into
push {regs}
but this is invalid. Conversely, it was also failing to translate
stmfd sp!, {lowregs[, lr]}
into a 16-bit push instruction. Fortunately stmia SP! is unlikely to be
a common idiom on a full-descending stack as it writes values to the stack,
then immediately deallocates that bit of the stack.
Fixed this and cleaned up the logic somewhat. While there, change some of
the ordering so that "ldm base, {base}" is transformed preferentially to
LDR. This is in keeping with the general preference in the Arm ARM for
avoiding single register LDM instructions.
So, typing Ctrl-o:
- executes the recalled command, and
- prefills the next one (which then can be executed again with Ctrl-o).
We have the same functionality in gdb, but when recalling the last command
from history with bash we have no prefill:
...
$ <echo 1>echo 1<enter>
1
$ <Ctrl-r>(reverse-i-search)`': <echo 1>echo 1<Ctrl-o>
1
$
...
but with gdb do we have a prefill:
...
(gdb) echo 1\n
1
(gdb) <Ctrl-r>(reverse-i-search)`': <echo 1>echo 1\n<Ctrl-o>
1
(gdb) echo 1\n
...
Following the principle of least surprise [2], I think gdb should do what bash
does.
Fix this by:
- signalling this case in gdb_rl_operate_and_get_next using
"operate_saved_history = -1", and
- handling operate_saved_history == -1 in
gdb_rl_operate_and_get_next_completion.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR cli/32485
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32485
Tom Tromey [Sun, 8 Dec 2024 00:28:30 +0000 (17:28 -0700)]
Use block::is_static_block in ada-lang.c
This changes one spot in ada-lang.c to use block::is_static_block
rather than a hand-rolled implementation. Note this also fixes the
call -- what is currently written there is wrong.
Tom de Vries [Fri, 20 Dec 2024 05:16:55 +0000 (06:16 +0100)]
[gdb/testsuite] Use -nostdlib in gdb.linespec/explicit.exp
On openSUSE Leap 15.6 ppc64le-linux, with gdb.linespec/explicit.exp I run
into:
...
(gdb) b -source thread_pointer.h FAIL: $exp: complete after -source: tab complete "b -source thr"
Quit^M
...
The test-case already contains a related workaround:
...
# Get rid of symbols from shared libraries, otherwise
# "b -source thr<tab>" could find some system library's
# source.
gdb_test_no_output "nosharedlibrary"
...
but that doesn't work in this case because the debug info is in the executable
itself:
...
The File Name Table (offset 0xb5):
Entry Dir Time Size Name
1 0 0 0 abi-note.c
2 1 0 0 types.h
3 2 0 0 stdint-intn.h
4 2 0 0 stdint-uintn.h
5 3 0 0 elf.h
6 4 0 0 thread_pointer.h
...
due to debug info in some glibc object file.
Fix this by:
- using -nostdlib, ensuring only debug info from the three test-case sources
is present in the executable, and
- adding a _start wrapping main.
Tested on x86_64-linux and ppc64le-linux.
Reviewed-By: Keith Seitz <keiths@redhat.com>
PR testsuite/31229
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31229
elfcpp/dwarf.h: Add post DWARF5 constants to DW_LANG enum
Also add the post DWARF5 language codes to gold/gdb-index.cc
Gdb_index_info_reader::visit_top_die check as --gdb-index only
supports C and C++ languages and emits warning otherwise.
gdb, gdbserver: introduce the 'x' RSP packet for binary memory read
Introduce an RSP packet, 'x', for reading from the remote server
memory in binary format. The binary write packet, 'X' already exists.
The 'x' packet is essentially the same as 'm', except that the
returned data is in binary format. For transferring relatively large
data from the memory of the remote process, the 'x' packet can reduce the
transfer costs.
For example, without this patch, fetching ~100MB of data from a remote
target takes
gdbserver: allow suppressing the next putpkt remote-debug log
When started with the --debug=remote flag, gdbserver enables the debug
logs for the received and sent remote packets. If the packet contents
are too long or contain verbatim binary data, printing the contents
may create noise in the logs or even distortion in the terminal output.
Introduce a function, `suppress_next_putpkt_log`, that allows omitting
the contents of a sent package in the logs. This can be useful when a
certain packet handler knows that it is sending binary data.
My first attempt was to implement this mechanism by passing an extra
parameter to putpt_binary_1 that could be controlled by the caller,
putpkt_binary or putpkt. However, all qxfer handlers, regardless of
whether they send binary or ascii data, cause the data to be sent via
putpkt_binary. Hence, the solution was going to be either too
suppressive or too intrusive. I opted for the approach where a package
handler would suppress the log explicitly.
Jan Beulich [Thu, 19 Dec 2024 09:39:38 +0000 (10:39 +0100)]
bfd/ELF: refine PR binutils/31872 fix
The fix for PR binutils/31872 (commit b20ab53f81db) neglected the case
of targets with only RELA support, where nevertheless object files using
REL exist. In particular objcopy will create such objects for x86-64
when converting from an i?86 ELF object (this by itself probably isn't
quite right, but we ought to cope with what our own tools are doing).
Restore the fallback to the RELA lookup, just without re-introducing the
blind NULL de-ref that was there before.
Alan Modra [Wed, 18 Dec 2024 08:29:41 +0000 (18:59 +1030)]
target_id for cr16 and vax
Both of these targets extend elf_link_hash_entry, so arguably should
set hash_table_id to something other than GENERIC_ELF_DATA. The patch
also sorts enum elf_target_id.
Alan Modra [Wed, 18 Dec 2024 07:06:01 +0000 (17:36 +1030)]
Add a few elf_backend_data target ids
aarch64, am33, csky, ia64-vms, kvx, and sparc64 all use more than
the base GENERIC_ELF_DATA, but don't set ELF_TARGET_ID. Fix that.
These are all targets that use other than GENERIC_ELF_DATA in their
object and hash table ids.
Keith Seitz [Wed, 18 Dec 2024 18:06:52 +0000 (10:06 -0800)]
[doc] Update gdb-add-index manpage
The current gdb-add-index manual page is a bit out-of-date. This
commit fixes a few deficiencies:
- gdb-add-index does not use objdump; it uses objcopy and readelf
- missing info on environment variables (in appropriate ENVIRONMENT section).
- missing mention of -dwarf-5 option
- adds important notice about FILENAME being writable
- explains exit status
- the script adds appropriate section(s) to the file; it does not
output new files with the section(s)
Tom Tromey [Wed, 17 Apr 2024 20:11:45 +0000 (14:11 -0600)]
Add an include-checking script
This adds a new Python script that checks the header guards of all gdb
source files. It enforces a fairly strict formatting and naming
scheme.
In particular, for a file "x/y-z.h" (relative to the repository root),
the include guard will be named "X_Y_Z_H". Only the '#ifndef' form is
allowed, not "#if !defined(...)". The trailing comment on the
"#endif" is also required.
The script also tries to update files that appear to have the required
lines if they are in the wrong form or use the wrong name.
Tom Tromey [Wed, 17 Apr 2024 20:30:56 +0000 (14:30 -0600)]
Fix some minor header file irregularities
The script in the next patch noticed some irregularities in some
headers: trailing or leading blank lines, or in one case a missing
copyright header. This patch fixes these.
projects / thirdparty / binutils-gdb.git / log
