Alan Modra [Wed, 1 Jan 2025 12:19:04 +0000 (22:49 +1030)]
gas tc_gen_reloc memory leaks
This makes all the tc_gen_reloc functions and the associated array in
write.c:write_relocs use notes_alloc rather than malloc. tc-hppa.c
tc_gen_reloc gets a few more changes, deleting some dead code, and
tidying code that duplicates prior initialisation.
Alan Modra [Wed, 1 Jan 2025 12:17:16 +0000 (22:47 +1030)]
gas dw2gencfi memory leaks
Some of these could have remained as malloc'd memory, but that would
require quite a bit of code to traverse frch_cfi_data for example, and
would rely on matching cfi directives (ie. valid input). Just put
them on the notes obstack instead.
* dw2gencfi.c (alloc_fde_entry): Use notes_calloc.
(alloc_cfi_insn_data): Likewise.
(cfi_end_fde): Don't free frch_cfi_data.
(cfi_add_label): Use notes_strdup.
(cfi_add_CFA_remember_state): Use notes_alloc.
(cfi_add_CFA_restore_state): Don't free.
(dot_cfi_escape): Use notes_alloc.
(cfi_finish): Free cies after each pass, not before. Clear
out static vars too.
Alan Modra [Wed, 1 Jan 2025 12:08:44 +0000 (22:38 +1030)]
gas include_dirs memory leak
This is the first of a series of patches aimed at making it possible
to configure with CFLAGS="-g -O2 -fsanitize=address,undefined" and run
the binutils and gas testsuite on x86_64-linux without using
ASAN_OPTIONS=detect_leaks=0. ie. the patch series is aimed at fixing
common gas, ar, objcopy, objdump, and readelf leaks.
* config/tc-tic54x.c (md_begin): Make use of notes_strdup rather
than xstrdup to copy entries added to include_dirs.
* read.c (read_end): Free include_dirs array.
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.
Tom Tromey [Thu, 19 Dec 2024 00:36:09 +0000 (17:36 -0700)]
Use 'flags' when expanding symtabs in gdbpy_lookup_static_symbols
This changes gdbpy_lookup_static_symbols to pass the 'flags' parameter
to expand_symtabs_matching. This should refine the search somewhat.
Note this is "just" a performance improvement, as the loop over
symtabs already checks 'flags'.
v2 also removes 'SEARCH_GLOBAL_BLOCK' and updates py-symbol.exp to
verify that this works properly. Thanks to Tom for this insight.
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.
Tom Tromey [Wed, 18 Dec 2024 15:34:31 +0000 (08:34 -0700)]
Fix typo in Python documentation
Oleg pointed out that when renaming from "status" to "enabled" in the
Python TUI events patch, I neglected to update one spot in the
documentation. This patch fixes this. I'm checking it in as obvious.
You can verify that this change is correct by examining
gdb/python/py-event-types.def.
Haochen Jiang [Wed, 18 Dec 2024 02:40:33 +0000 (10:40 +0800)]
Support Intel SM4 AVX10.2 extension
In this patch, we will support SM4 AVX10.2 extension part. It is
a promotion from VEX encoding to EVEX encoding. The EVEX encoding
is based on AVX10.2, which is the same as the upcoming MOVRS ISA.
Thus, we decide to pull AVX10.2 out to CPU_COMMON_FLAGS.
While I have also tried to merge the table like AVX/AVX512, I
choose to just templatize the table. I am okay to go either way,
but slightly prefer the templatizing one since probably SM4 would
be the only ISA with AVX10.2 needs such VEX to EVEX extension (MOVRS
does not need that). Also, it is a tendancy that we will directly
provide EVEX encodings and no VEX encodings for vector instructions
since AVX10. This will make the adding in gas/config/tc-i386.c not
that worthy.
Tom Tromey [Tue, 17 Dec 2024 19:13:22 +0000 (12:13 -0700)]
Minor C++-ification in rust-parse.c
This patch changes a few spots in rust-parse.c to use 'bool', and also
declares a couple of loop iteration variables in the loop headers.
I'm checking this in.
Tiezhu Yang [Mon, 16 Dec 2024 07:03:05 +0000 (15:03 +0800)]
gdb: syscalls: Update ARM64 xml files
There are some new syscalls in the latest upstream Linux kernel [1],
some archs updated the xml files in the recent commit 19f3450f7429
("[gdb/syscalls] Add syscalls {set,get,list,remove}xattrat"), also
update ARM64 to reflect the reality.
Tiezhu Yang [Mon, 16 Dec 2024 07:03:03 +0000 (15:03 +0800)]
gdb: syscalls: Remove tips for LoongArch xml files
After commit "gdb: syscalls: Handle __NR3264_ prefixed syscall number",
no need to do special handling when generating xml file for LoongArch,
just remove the tips in the file comment.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Approved-By: Tom de Vries <tdevries@suse.de>
Tiezhu Yang [Mon, 16 Dec 2024 07:03:02 +0000 (15:03 +0800)]
gdb: syscalls: Handle __NR3264_ prefixed syscall number
In gdb commit a08dc2aa004b ("gdb: syscalls: Add loongarch-linux.xml.in"),
we find:
There exist some __NR3264_ prefixed syscall numbers, replace them
with digital numbers according to /usr/include/asm-generic/unistd.h
and sort them by syscall number manually, maybe we can modify the
script to do it automatically in the future.
It is time to do it now, just handle __NR3264_ prefixed syscall number
automatically in the script update-linux.sh.
By the way, a Linux kernel patch did the similar change [1].
Matthieu Longo [Mon, 1 Jul 2024 10:33:47 +0000 (11:33 +0100)]
aarch64: testsuite: remove macro expansion messages from expected error output
gas generates an information diagnostic message for every context
invoking a macro and generating a warning or error message.
For the specific case of sysreg tests, this pollutes the expected
error output for no benefit in term of test debug or testing coverage.
This patch aims at stopping such diagnostic messages to be generated
for the failure tests by providing --no-info flag to gas.
It also removed from the expected outputs the information messages
related to macro expansions.
Matthieu Longo [Thu, 27 Jun 2024 10:02:18 +0000 (11:02 +0100)]
gas: add new command line options to control diagnostic informational messages
gas currently emits informational messages for context information along warnings.
In the context of system register tests in AArch64 backend, these messages
pollute the tests when checking for error message patterns in stderr output.
This patch aims at providing two new flags while preserving the existing
behavior if none of the options is provided.
* --info, similar to the existing --warn flag to enable diagnostic
informational messages (default behavior).
* --no-info, similar to the existing --no-warn flag to disable diagnostic
informational messages.
It also adds the flags to the existing documentation, and command manual.
gdbserver: return tracked register status in regcache_raw_read_unsigned
In regcache_raw_read_unsigned, we unconditionally return REG_VALID as
the register status. This does not seem right, since the register may
in fact be in another state, such as REG_UNAVAILABLE. Return the
tracked status.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
gdbserver: rename regcache's registers_valid to registers_fetched
The registers_valid field of the regcache struct is used for tracking
whether we have attempted to fetch all the registers from the target.
Its name does not reflect this well, I think. It falsely gives the
impression that all the registers are valid. This may conflict an
individual register status, which could be REG_UNAVAILABLE. To better
reflect the purpose, rename the field to "registers_fetched".
Approved-By: Simon Marchi <simon.marchi@efficios.com>
gdbserver: check for nullptr condition in regcache::get_register_status
A regcache can be initialized with a register value buffer, in which
case, the register_status pointer is null. This condition is checked
in set_register_status, but not in get_register_status. Do this check
for consistence and safety.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
gdbserver: boolify and defaultize the 'fetch' parameter of get_thread_regcache
Boolify the 'fetch' parameter of the get_thread_regcache function.
All of the current uses pass true for this parameter. Therefore, define
its default value as true and remove the argument from the uses.
We still keep the parameter, though, to give downstream targets the
option to obtain a regcache without having to fetch the whole
contents. Our (Intel) downstream target is an example.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
The `get_thread_regcache` function has a `fetch` option to skip
fetching the registers from the target. It seems this option is set
to false only at uses where we just need to access the tdesc through
the regcache of the current thread, as in
Since the tdesc of a regcache is set from the process of the thread
that owns the regcache, we can simplify the code to access the tdesc
via the process, as in
... current_process ()->tdesc ...
This is intended to be a refactoring with no behavioral change.
Tested only for the linux-x86-low target.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Sat, 16 Nov 2024 17:34:35 +0000 (10:34 -0700)]
Import GNU Readline 8.2
This imports readline 8.2 patch 13.
This time around I thought I would try to document the process.
First I have a checkout of the upstream readline repository. I make a
local branch there, based on the previous upstream import. In this
case that was readline 8.1; see gdb commit b4f26d541aa.
Then, I apply all readline changes from the gdb repository since the
previous readline import. In this case that is up to commit 3dee0baea2e in the gdb repo.
After this, I "git merge" from the relevant upstream commit. In the
past I feel like I used a tag, but readline is managed very strangely
and I didn't see a tag. So I just used the patch 13 commit, aka
commit 037d85f1 upstream.
Then I fixed all the merge conflicts. Re-running autoconf requires a
symlink from '../../config' into the gdb tree, due to the local
m4_include addition. It's possible other hacks like this are
required, I don't remember how I set things up in the past.
After this, I did a build + test of gdb. I also did a mingw
cross-hosted build, because that's caused build failures in past
imports.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32265 Reviewed-by: Sam James <sam@gentoo.org>
Tom Tromey [Thu, 6 Jun 2024 15:42:15 +0000 (09:42 -0600)]
Greatly speed up rbreak
While debugging another issue, I noticed that 'rbreak' on a large
program was very slow. In particular, with 'maint time 1':
(gdb) with pagination off -- rbreak ^command_display
[...]
Command execution time: 1940.646332 (cpu), 1960.771517 (wall)
"ps" also reported that, after this command, gdb's VSZ was 4619360.
Looking into this, I found something strange. When 'rbreak' found a
function "f" in file "file.adb", it would try to set the breakpoint
using "break 'file.adb':'f'".
This then interacted somewhat poorly with linespec. linespec first
expands all the symtabs matching "file.adb", but in this program this
results in thousands of CU expansions (probably due to inlining, but I
did not investigate).
There is probably a linespec bug here. It would make more sense for
it to combine the file- and symbol- lookups, as this is more
efficient. I plan to file a bug about this at least.
I tracked this "file:function" style of linespec to the earliest days
of gdb. Back then, "break function" would only break on the first
"function" that was found -- it wasn't until much later that we
changed gdb to break on all matching functions. So, I think that
rbreak was written this way to try to work around this limitation, and
it seems to me that this change obsoleted the need for rbreak to
mention the file at all.
That is, "break file:function" is redundant now, because plain
"break function" will redo that same work -- just more efficiently.
(The only exception to this is the case where a file is given
to rbreak -- here the extra filtering is still needed.)
This patch implements this. On the aforementioned large program, with
this patch, rbreak still sets all the desired breakpoints (879 of
them) but is now much faster:
(gdb) with pagination off -- rbreak ^command_display
[...]
Command execution time: 91.702648 (cpu), 92.770430 (wall)
Tom Tromey [Fri, 24 May 2024 16:51:02 +0000 (10:51 -0600)]
Don't let exception terminate 'rbreak'
'rbreak' searches symbols and then sets a number of breakpoints. If
setting one of the breakpoints fails, then 'rbreak' will terminate
before examining the remaining symbols.
However, it seems to me that it is better for 'rbreak' to keep going
in this situation. That is what this patch implements.
This problem can be seen by writing an Ada program that uses "pragma
import" to reference a symbol that does not have debug info. In this
case, the program will link but setting a breakpoint on the imported
name will not work.
I don't think it's possible to write a reliable test for this, as it
depends on the order in which symtabs are examined.
New in v2: rbreak now shows how many breakpoints it made and also how
many errors it encountered.
projects / thirdparty / binutils-gdb.git / log
