The 'univeral_compile_options' in gdb.exp file only verifies the support
of '-fdiagnostics-color=never' for the "C" source file. So while running
tests with assembly source file (.s), many of them are not able to run
on icx/clang compilers because '-fdiagnostics-color=never' option is not
supported. This problem is not seen for the ".S" assembly source files so
these files are not handled separately. After this change, this function
is split into multiple functions to check the support for different type
of sources individually.
Before this change, in the case of clang and ICX compiler, this error is
shown for assembly source files (.s):
Simon Marchi [Thu, 16 May 2024 16:55:01 +0000 (12:55 -0400)]
gdb: define type aliases for `fork_inferior()` callbacks
The `fork_inferior()` function accepts multiple callbacks, making its
signature a bit hard to read. Define some type aliases to make it a bit
clearer. Use function view for all, while at it.
Change-Id: Ide8d1fa533d0c5eaf3249860f8c0d339baa09bce Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Thu, 16 May 2024 16:35:53 +0000 (12:35 -0400)]
gdb: initialize packet_result::m_textual_err_msg
When building GDB with -O2 and --enable-ubsan, I get some random errors
in the packet_result self test:
/home/smarchi/src/binutils-gdb/gdb/remote.c:161:7: runtime error: load of value 92, which is not a valid value for type 'bool'
This happens because packet_result::m_textual_err_msg is uninitialized
when using the second constructor. When such a packet_result object
gets copied, an invalid value for m_textual_err_msg (a bool field) is
loaded, which triggers ubsan.
Avoid this by initializing m_textual_err_msg.
Change-Id: I3ce44816bb0bfc6e442067292f993e5c17301b85 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Wed, 15 May 2024 17:13:27 +0000 (13:13 -0400)]
gdb: move lm_info to solib in dsbt_current_sos
Commit 8971d2788e79 ("gdb: link so_list using intrusive_list")
mistakenly removed the line that moves the lm_info unique pointer to
sop->lm_info, probably due to a bad conflict resolution. Restore that
line.
Unfortunately, this code is only used for TI C66, which is not widely
tested (if used at all).
Change-Id: I9f64eb4430c324bc93ddb4bd00d820dee34adfbb Approved-By: Tom Tromey <tom@tromey.com>
aarch64: fp8 convert and scale - add sme2 insn variants
Add the SME2 variant of the FP8 convert and scale
instructions, enabled at assembly-time using the `+sme2+fp8'
architectural extension flag. More specifically, support is
added for the following instructions:
Multi-vector floating-point convert from FP8 to
BFloat16 (in-order):
-----------------------------------------------
aarch64: fp8 convert and scale - add sve2 insn variants
Add the SVE2 variant of the FP8 convert and scale instructions,
enabled at assembly-time using the `+sve2+fp8' architectural
extension flag. More specifically, support is added for the
following instructions:
FP8 convert to BFloat16 (bottom/top):
-------------------------------------
aarch64: fp8 convert and scale - Add advsimd insn variants
Add the advanced SIMD variant of the FP8 convert and scale
instructions, enabled at assembly-time using the `+fp8'
architectural extension flag. More specifically, support is
added for the following instructions:
FP8 convert to BFloat16 (vector):
---------------------------------
Pedro Alves [Tue, 14 May 2024 14:43:41 +0000 (15:43 +0100)]
Stop 'configure --enable-threading' if std::thread doesn't work
Currently, if you configure gdb with explicit --enable-threading, but
then configure detects std::thread does not work, configure silently
disables threading support and continues configuring.
This patch makes that scenario cause a configuration error, like so:
Richard Earnshaw [Wed, 15 May 2024 15:06:28 +0000 (16:06 +0100)]
arm: remove incorrect handling of FP bignums in move_or_literal_pool
This hunk of code in move_or_literal_pool just looks wrong, but I
can't find a testcase that will tickle it to prove it. It looks a bit
like it was intended to catch cases where a bignum contained a
floating-point value, but there were a number of problems with it.
- It tested X_add_number == -1, but an FP bignum is indicated by any
value <= 0.
- It converted the floating-point value to extended precision, but
that's not used on Arm beyond the legacy FPA code. No attempt was
made to match the FP value to the intended memory/mov operation.
Since I can't construct a viable testcase, I've just removed the existing
code and made the function error out in this case: this seems more sensible
than generating wrong code or trying to write something more complex that
can't be tested anyway.
Matthieu Longo [Tue, 27 Feb 2024 10:59:16 +0000 (10:59 +0000)]
aarch64: testsuite: reorder write and read to match macro order
This patch aims at grouping write and read for a same system register
one after another so that the diff for the macro replacement does not
generate too much noise.
Matthieu Longo [Tue, 27 Feb 2024 10:59:15 +0000 (10:59 +0000)]
aarch64: testsuite: use same regs for read and write tests
This patch aims at making easier to replacement of read and write
instructions to system registers by a macro that will use the same
registers for read and write.
Matthieu Longo [Tue, 27 Feb 2024 10:59:14 +0000 (10:59 +0000)]
aarch64: testsuite: replace instruction addresses by regex
This patch removes the instruction addresses from the objdump's expected
output (.d files). The intended benefit from this clean-up is to allow to
swap lines around more easilly, and removes the noise of patches that add,
remove or reorder instructions.
Tom de Vries [Wed, 15 May 2024 07:45:55 +0000 (09:45 +0200)]
[binutils/readelf] Fix handling of DW_MACRO_define_strx in dwo file
When printing a DW_MACRO_define_strx entry in a .debug_macro.dwo section, we
run into:
...
DW_MACRO_define_strx lineno : 0 macro : <no .debug_str_offsets section>
...
Fix this in display_debug_macro by passing the correct dwo argument to a
fetch_indexed_string call.
That works fine for readelf -w, with with readelf -wm we have:
...
DW_MACRO_define_strx lineno : 0 macro : <no .debug_str_offsets.dwo section>
...
Fix this in display_debug_macro by doing load_debug_section_with_follow for
str_dwo / str_index_dwo sections instead of str / str_index sections when
handling .debug_macro.dwo.
Tom de Vries [Wed, 15 May 2024 07:45:55 +0000 (09:45 +0200)]
[binutils/readelf] Fix printing of dwarf4 .debug_str_offsets.dwo
When compiling a hello world with dwarf4 split dwarf:
...
$ gcc -gdwarf-4 -gsplit-dwarf hello.c -save-temps -dA
...
we have in a-hello.s these three initial entries in .debug_str_offsets:
...
.section .debug_str_offsets.dwo,"e",@progbits
.4byte 0 // indexed string 0x0: short int
.4byte 0xa // indexed string 0x1: /home/vries/binutils
.4byte 0x1f // indexed string 0x2: main
...
but "readelf -ws a.out" starts at the third entry:
...
Contents of the .debug_str_offsets.dwo section (loaded from a-hello.dwo):
Length: 0x30
Index Offset [String]
0 00000000 main
...
This is a regression since commit 407115429b3 ("Modified changes for
split-dwarf and dwarf-5."), which introduced a variable
debug_str_offsets_hdr_len in display_debug_str_offsets.
Fix this by setting display_debug_str_offsets to 0 for the dwarf4 case.
Joseph Faulls [Tue, 14 May 2024 22:59:58 +0000 (06:59 +0800)]
RISC-V: Search for mapping symbols from the last one found
With previous behaviour, multiple mapping symbols within the same
function would result in all the mapping symbols being searched.
This could slow down disassembly dramatically.
Multiple mapping symbols within a function can be a result of encoding
instructions as data, like sometimes seen in random instruction
generators.
opcodes/ChangeLog:
* riscv-dis.c (riscv_search_mapping_symbol): Use last mapping
symbol if it exists.
Tom Tromey [Sat, 20 Apr 2024 22:33:37 +0000 (16:33 -0600)]
Add spaceship operator to cp-name-parser.y
While debugging gdb, I saw this:
During symbol reading: unexpected demangled name 'operator<=><std::chrono::_V2::system_clock, std::chrono::duration<long int>, std::chrono::duration<long int> >'
This happens because cp-name-parser.y does not handle the spaceship
operator. This patch implements this.
Tom Tromey [Sat, 20 Apr 2024 02:22:11 +0000 (20:22 -0600)]
Implement C++14 numeric separators
C++14 allows the use of the apostrophe as a numeric separator; that
is, "23000" and "23'000" represent the same number. This patch
implements this for gdb's C++ parser and the C++ name canonicalizer.
I did this unconditionally for all C variants because I think it's
unambiguous.
For the name canonicalizer, there's at least one compiler that can
emit constants with this form, see bug 30845.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23457
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30845 Approved-By: John Baldwin <jhb@FreeBSD.org>
Tom Tromey [Thu, 11 Apr 2024 18:43:06 +0000 (12:43 -0600)]
Fix C++ canonicalization of hex literals
Currently names like "x::y::z<1>" and "x::y::z<0x01>" canonicalize to
different things. I think it's nicer for them to be the same.
Differences between types can be done using suffixes like "ll" and "u"
-- it's not really possible to implement C++ rules in the
canoncalizer, because no gdbarch is available. Possibly gdb should
even drop the type here and just represent all integers the same way
in names.
Tom Tromey [Fri, 12 Apr 2024 02:00:09 +0000 (20:00 -0600)]
Remove some unnecessary allocations from cpname_state::parse_number
cpname_state::parse_number allocates nodes for various types and then
only uses one of them. This patch reduces the number of allocations
by not performing the unnecessary ones.
Tom Tromey [Wed, 10 Apr 2024 22:49:51 +0000 (16:49 -0600)]
Fix C++ name canonicalizations of character literals
The names "void C<(char)1>::m()" and "void C<'\001'>::m()" should
canonicalize to the same string, but currently they do not -- the
former remains unchanged and the latter is transformed to
"void C<(char)'\001'>::m()".
This patch fixes the bug and also adds some unit tests.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16843 Approved-By: John Baldwin <jhb@FreeBSD.org>
Tom Tromey [Thu, 11 Apr 2024 16:35:09 +0000 (10:35 -0600)]
Change storage of demangle_component
This changes demangle_component objects to be stored on the obstack
that is part of demangle_info. It also arranges for a demangle_info
object to be kept alive by cp_merge_demangle_parse_infos. This way,
other data on the obstack can be kept while an "outer" demangle_info
needs it.
Tom Tromey [Wed, 17 Apr 2024 14:04:59 +0000 (08:04 -0600)]
Disallow trailing whitespace in docstrings
This patch changes the docstring self-test to verify that there is no
trailing whitespace at the end of lines. A few existing docstrings
had to be updated.
Tom Tromey [Fri, 26 Apr 2024 16:32:07 +0000 (10:32 -0600)]
Remove fflush call from tui_refresh_cmd_win
tui_refresh_cmd_win calls fflush, but there's a comment explaining
that the reason for the call is unknown. This patch removes the call.
I don't think it can be useful, since gdb doesn't generally use stdout
in this way -- only through ui_file.
Andrew Burgess [Sat, 11 May 2024 08:44:07 +0000 (09:44 +0100)]
gdb/doc: don't delete *.pod files too early
When doing 'make -C gdb/doc man' to build the man pages, I noticed
that the outputs were being rebuilt each time the make command was
rerun, even when the input files hadn't changed.
Which split the generation of the .pod file from the actual creation
of the man page file. Prior to this split it was OK to delete the
.pod file at the end of the recipe, the rule depending on the .texi
input file, and output was the .1 or .5 man page file.
Now however, with the split, the man page creation depends on the .pod
file, if we delete this after creating the .1 or .5 man page file then
the next time we run 'make' the .pod file is missing and is
regenerated, which in turn triggers the regeneration of the man page
file.
Fix this by leaving the .pod file around, and only cleaning up these
files in the 'mostlyclean' target.
Which leads to a second problem, the POD_FILE_TMPS is not created
correctly, so we don't actually clean up the .pod files! This too is
fixed in this commit.
After this commit running 'make -C gdb/doc man' will build the manual
pages the first time, and each subsequent run will do nothing.
Running 'make -C gdb/doc mostlyclean' will now delete the .pod files.
While working on another patch I needed to pass -Wl,-soname,NAME as a
compiler flag. I initially looked for other tests that did this, and
found a few examples, so I copied what they did.
But when I checked the gdb.log file I noticed that we were actually
getting -Wl,-soname passed twice.
I tracked the repeated option to 'proc gdb_compile_shlib_1' in
lib/gdb.exp. It turns out that we always add -Wl,-soname when
compiling a shared library.
Here's an example of a build command from gdb.base/prelink.exp:
I believe that all of the places where tests add '-Wl,-soname,NAME' as
a build option, are unnecessary.
In this commit I propose we remove them all.
As part of this change I've switched from calling gdb_compile_shlib
directly, to instead call build_executable and adding the 'shlib'
flag.
I've tested with gcc and clang and see no changes in the test results
after this commit. All the compile commands still have -Wl,-soname
added, but now it's only added once, from within lib/gdb.exp.
There should be no change in what is tested after this commit.
Jason Merrill [Fri, 10 May 2024 20:33:20 +0000 (16:33 -0400)]
Adjust C++ destructor type tests
In gcc-15-95-ga12cae97390 I dropped the unnecessary artificial "in-charge"
parameter from destructors of classes with no virtual bases; Linaro's CI
informed me that the gdb testsuite needs to be adjusted to match.
Fix Segmentation Fault in AIX during multi process debugging.
Due to the recent commit in aix-thread.c, we see a segmentation fault
in AIX while debugging multiple process involving multiple threads.
One example is a thread that can fork. The GDB output in AIX for the same is
Reading symbols from //gdb_tests/multi-thread-fork...
(gdb) set detach-on-fork off
(gdb) r
Starting program: /gdb_tests/multi-thread-fork
[New Thread 258 (tid 67110997)]
[New Thread 515 (tid 127404289)]
[New inferior 2 (process 16580940)]
Hello from Parent!
[process 16580940 exited]
[New inferior 3 (process 14549318)]
Hello from Parent!
[process 14549318 exited]
Fatal signal: Segmentation fault
----- Backtrace -----
This is because in sync_threadlists () in aix-thread.c there when we
delete threads in unknown state we iterate through all the threads.
When we have one or more threads with the same user thread ID but of different
process then we delete a wrong thread. Since we just check only the pdtid
in in_queue_threads.count (priv->pdtid) == 0 this happened.
This patch is a fix for the same.
The output after we apply this patch is:
Reading symbols from //gdb_tests/multi-thread-fork...
(gdb) set detach-on-fork off
(gdb) r
Starting program: /gdb_tests/multi-thread-fork
[New Thread 258 (tid 75565441)]
[New Thread 515 (tid 63244397)]
[New inferior 2 (process 10813892)]
Hello from Parent!
[New inferior 3 (process 19005888)]
Hello from Parent!
Thread 1.1 received signal SIGINT, Interrupt.
0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o)
(gdb) info threads
Id Target Id Frame
* 1.1 Thread 1 (tid 66062355) ([running]) 0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o)
1.2 Thread 258 (tid 75565441) ([running]) thread_function (arg=0x0) at //gdb_tests/multi-thread-fork.c:50
1.3 Thread 515 (tid 63244397) ([running]) thread_function (arg=0x0) at //gdb_tests/multi-thread-fork.c:50
2.1 Thread 515 (tid 32113089) ([running]) 0xd0610df0 in _sigsetmask () from /usr/lib/libpthread.a(_shr_xpg5.o)
3.1 Thread 258 (tid 64489699) ([running]) 0xd0610df0 in _sigsetmask () from /usr/lib/libpthread.a(_shr_xpg5.o)
(gdb) q
A debugging session is active.
Richard Earnshaw [Mon, 29 Apr 2024 12:59:38 +0000 (13:59 +0100)]
arm: opcodes: remove Maverick disassembly.
Remove the patterns to match Maverick co-processor instructions from
the disassembly tables.
This required fixing a couple of tests in the assembler testsuite
where we, probably incorrectly, disassembled generic co-processor
instructions as a Maverick instruction (it particularly made no sense
to do this for Armv6t2 in Thumb state).
Richard Earnshaw [Mon, 29 Apr 2024 12:27:30 +0000 (13:27 +0100)]
arm: remove Maverick support from the assembler.
Delete all the Maverick instructions and register handling from the
assembler. We continue to recognize -mcpu=ep9312, but treat it as an
alias for arm920t. We no-longer recognize -mfpu=maverick.
Tom de Vries [Sat, 11 May 2024 07:56:45 +0000 (09:56 +0200)]
[gdb/testsuite] Fix Wreturn-mismatch in gdb.base/list-dot-nodebug.exp
When running test-case gdb.base/list-dot-nodebug.exp in a fedora rawhide
container, I run into:
...
temp/$pid/static-libc.c: In function 'main':
temp/$pid/static-libc.c:2:42: error: 'return' with a value, in function
returning void [-Wreturn-mismatch]
2 | void main (void) { return 0; }
| ^
...
UNTESTED: gdb.base/list-dot-nodebug.exp: Can't statically link
...
Tom Tromey [Wed, 24 Apr 2024 16:03:08 +0000 (10:03 -0600)]
Add symbol, line, and location to DAP disassemble result
The DAP spec allows a number of attributes on the resulting
instructions that gdb currently does not emit. A user requested some
of these, so this patch adds the 'symbol', 'line', and 'location'
attributes. While the spec lets the implementation omit 'location' in
some cases, it was simpler in the code to just always emit it, as then
no extra tracking was needed.
Tom Tromey [Wed, 24 Apr 2024 17:58:38 +0000 (11:58 -0600)]
Implement tp_richcompare for gdb.Block
I noticed that two gdb.Block objects will never compare as equal with
'=='. This patch fixes the problem by implementing tp_richcompare, as
was done for gdb.Frame.
Tom Tromey [Wed, 24 Apr 2024 15:53:55 +0000 (09:53 -0600)]
Simplify DAP make_source callers
A couple callers of make_source call basename by hand. Rather than
add another caller like this, I thought it would be better to put this
ability into make_source itself.
Alan Modra [Fri, 10 May 2024 12:45:06 +0000 (22:15 +0930)]
Re: PR31692, objdump fails .debug_info size check
The fuzzers found a hole. bfd_section_size_insane doesn't check
!SEC_HAS_CONTENTS sections against file size for obvious reasons,
which allows fuzzed debug sections to be stupidly large. Real debug
sections of course always have contents.
PR 31692
* objdump.c (load_specific_debug_section): Don't allow sections
without contents.
Andrew Burgess [Sun, 5 May 2024 10:00:04 +0000 (11:00 +0100)]
gdb: add gdbarch_stack_grows_down function
In another patch I'm working on I needed to ask: does the stack grow
down, or grow up?
Looking around I found in infcall.c some code where we needed to ask
the same question, what we do there is ask:
gdbarch_inner_than (gdbarch, 1, 2)
which should do the job. However, I don't particularly like copying
this, it feels like we're asking something slightly different that
just happens to align with the question we're actually asking.
I propose adding a new function `gdbarch_stack_grows_down`. This is
not going to be a gdbarch method that can be overridden, instead, this
will just call the gdbarch_inner_than function. We already have some
gdbarch methods like this, checkout arch-utils.c for examples.
I think it's now clearer what we're actually doing.
A new self-test ensures that all architectures have a stack that
either grows down, or grows up.
There should be no user visible changes after this commit.
Pedro Alves [Thu, 9 May 2024 12:01:53 +0000 (13:01 +0100)]
gdb sim testing, set gdb_protocol to "sim"
Bernd reported that when testing with riscv-unknown-elf target using
the simulator, before commit c7a2ee649115 ("gdb_is_target_native ->
gdb_protocol_is_native"), he had:
PASS: gdb.base/load-command.exp: probe for target native
PASS: gdb.base/load-command.exp: check initial value of the_variable
PASS: gdb.base/load-command.exp: manually change the_variable
PASS: gdb.base/load-command.exp: check manually changed value of the_variable
PASS: gdb.base/load-command.exp: reload: re-load binary
PASS: gdb.base/load-command.exp: reload: check initial value of the_variable
and now:
UNSUPPORTED: gdb.base/load-command.exp: the native target does not support the load command
The problem is that the sim board/config isn't setting gdb_protocol
anywhere, so gdb_protocol_is_native returns true.
This commit fixes it by making gdb/testsuite/config/sim.exp set
gdb_protocol to "sim".
Tom de Vries [Fri, 10 May 2024 06:46:21 +0000 (08:46 +0200)]
[gdb/python] Make gdb.UnwindInfo.add_saved_register more robust (fixup)
In commit 2236c5e384d ("[gdb/python] Make gdb.UnwindInfo.add_saved_register
more robust") I added this code in unwind_infopy_add_saved_register:
...
if (value->optimized_out () || !value->entirely_available ())
...
which may throw c++ exceptions.
This needs to be caught and transformed into a python exception.
Fix this by using GDB_PY_HANDLE_EXCEPTION.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com> Fixes: 2236c5e384d ("[gdb/python] Make gdb.UnwindInfo.add_saved_register more robust")
Bernd Edlinger [Thu, 9 May 2024 05:58:08 +0000 (07:58 +0200)]
sim: riscv: Fix build issue due to recent binutils commit
The commit c144f6383379 removed INSN_CLASS_A and
added INSN_CLASS_ZAAMO and INSN_CLASS_ZALRSC instead,
which broke the build of the sim for riscv targets.
Fix that by using the new INSN_CLASS types.
Fixes: c144f6383379 ("RISC-V: Support B, Zaamo and Zalrsc extensions.") Approved-By: Tom Tromey <tom@tromey.com>
Andrew Burgess [Mon, 6 May 2024 18:54:27 +0000 (19:54 +0100)]
gdb: add a new build_id_equal function
Add two versions of a new function build_id_equal which can be used to
compare build-ids, then make use of these functions in GDB. It seems
better to have a specific function for the task of comparing build-ids
rather than having a length check followed by a memcmp call.
There should be no user visible changes after this commit.
When running 'make check', the default gprofng test suite creates a
shell script for which it used a hardcoded shebang of '/usr/bin/bash'
this script would not run if bash is in a different location, like
/bin/bash
This commit adds 'AC_PATH_PROG(BASH, bash)' to configure.ac so the
installation path of bash is detected at configuration time. The
configuration is propagated to the runtest command line where it is
needed.
Andrew Burgess [Fri, 12 Apr 2024 16:47:20 +0000 (17:47 +0100)]
gdb/doc: use silent-rules.mk in the Makefile
Make use of silent-rules.mk when building the GDB docs.
During review it was requested that there be more specific rules than
just reusing the general 'GEN' rule everywhere in the doc/ directory,
so I've added:
Then I've made use of these new silent rules and added lots of uses of
SILENT to reduce additional clutter.
As the man page generation is done in two phases, first the creation
of a .pod file, then the creation of the final man page file, I've
restructured the man page rules. Previously we had one rule for each
of the 5 man pages. I now have one general rule that will generate
all of the 5 .pod files, then I have two rules that convert the .pod
files into the final man pages.
I needed two rules for the man page generation as some man pages match
%.1 and some match %.5. I could combine these by using the GNU Make
.SECONDARYEXPANSION extension, but I think having two rules like this
is probably clearer, and the duplication is minimal.
Cleaning up the temporary .pod files is now moved into the
'mostlyclean' target rather than being done as soon as the man page is
created.
I've added a new SILENT_Q_FLAG to silent-rules.mk, this is like
SILENT_FLAG, but is set to '-q' when in silent mode, this can be used
with the 'dvips' and 'texi2dvi' commands, both of which use '-q' to
mean: only report errors.
As with the rest of the GDB makefiles, I've only converted the
"generation" rules to use silent-rules.mk, the install / uninstall
rules are left unchanged.
When looking at the 'diststuff' target, which generates the info and
man pages, I noticed the recipe for this rule just deleted a temporary
file. As that temporary file is already cleaned up as part of the
'clean' rule I've removed the deletion from the 'diststuff' target.
There are still a few "generation" targets that produce output, there
seems to be no flag to silence the 'tex' and 'pdftex' commands which
some recipes use, I've not worried about these for now, e.g. the
refcard.dvi and refcard.pdf targets still produce some output.
Luckily, when doing a 'make all' in the gdb/ directory, we only build
the info docs by default, and those rules are now nice and silent, so
a complete GDB build is now looking nice and quiet by default.
While working on this patch I noticed that 'make -j all-doc' doesn't
work (reliably), this is a preexisting bug in the way that dvi/pdf
targets are generated. For example gdb.dvi and gdb.pdf both use the
texi2dvi tool, which relies on temporary files to hold state. If both
these rules run in parallel then one (or both) of the recipes will
fail.
Luckily, the default docs target (all), which is what gets run when we
do 'make all' in the gdb/ directory, doesn't build the dvi and pdf
targets, so we're OK in that case.
I've not tried to fix this problem in this commit as it already
existed, and I don't want to do too much in one commit. I mention it
only because I ran into this issue while testing this commit.
Guinevere Larsen [Tue, 13 Feb 2024 14:36:23 +0000 (15:36 +0100)]
gdb: Change "list ." command's error when no debuginfo is available
Currently, when a user tries to list the current location, there are 2
different error messages that can happen, either:
(gdb) list .
No symbol table is loaded. Use the "file" command.
or
(gdb) list .
No debug information available to print source lines.
The difference here is if gdb can find any symtabs at all or not, which
is not something too important for end-users - and isn't informative at
all. This commit changes it so that the error always says that there
isn't debug information available, with these two variants:
(gdb) list .
Insufficient debug info for showing source lines at current PC (0x55555555511d).
or
(gdb) list .
Insufficient debug info for showing source lines at default location.
The difference now is if the inferior has started already, which is
controlled by the user and may be useful.
Unfortunately, it isn't as easy to differentiate if the symtab found for
other list parameters is correct, so other invocations, such as "list +"
still retain their original error message.
Co-Authored-By: Simon Marchi <simark@simark.ca> Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
Fix AIX thread exit events not being reported and UI to show kernel thread ID.
In AIX when a thread exits we were not showing that a thread exit event happened
and GDB continued to keep the terminated threads.
If we have terminated threads then the UI on info threads command will look like
(gdb) info threads
Id Target Id Frame
* 1 Thread 1 (tid 26607979, running) 0xd0611d70 in _p_nsleep () from /usr/lib/libpthreads.a(_shr_xpg5.o)
2 Thread 258 (tid 30998799, finished) aix-thread: ptrace (52, 30998799) returned -1 (errno = 3 The process does not exist.)
If we see the frame is not getting displayed correctly.
The reason for the same is that in AIX we were not managing thread states. In particular we do not know
when a thread terminates.
The reason being in sync_threadlists () the pbuf and gbuf lists remain the same though certain threads exit.
This patch is a fix to the same.
Also certain UI is changed.
On a new thread born and exit the UI in AIX will be similar to Linux with both user and kernel thread information.
and info threads will look like
(gdb) info threads
Id Target Id Frame
* 1 Thread 1 (tid 31326579) ([running]) 0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o)
Also a small change to testcase gdb.threads/thread_events.exp to make sure this test runs on AIX as well.
Tom de Vries [Wed, 8 May 2024 12:13:11 +0000 (14:13 +0200)]
[gdb/python] Make gdb.UnwindInfo.add_saved_register more robust
On arm-linux, until commit bbb12eb9c84 ("gdb/arm: Remove tpidruro register
from non-FreeBSD target descriptions") I ran into:
...
FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 5: \
backtrace when the unwind is broken at frame 5
...
What happens is the following:
- the TestUnwinder from inline-frame-cycle-unwind.py calls
gdb.UnwindInfo.add_saved_register with reg == tpidruro and value
"<unavailable>",
- pyuw_sniffer calls value->contents ().data () to access the value of the
register, which throws an UNAVAILABLE_ERROR,
- this causes the TestUnwinder unwinder to fail, after which another unwinder
succeeds and returns the correct frame, and
- the test-case fails because it's counting on the TestUnwinder to succeed and
return an incorrect frame.
Fix this by checking for !value::entirely_available as well as
valued::optimized_out in unwind_infopy_add_saved_register.
Tested on x86_64-linux and arm-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
PR python/31437
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31437
Nelson Chu [Mon, 5 Feb 2024 01:39:37 +0000 (09:39 +0800)]
RISC-V: Support B, Zaamo and Zalrsc extensions.
* https://github.com/riscv/riscv-b/tags
Added standard B extension back, which implies Zba, Zbb and Zbs extensions.
* https://github.com/riscv/riscv-zaamo-zalrsc/tags
Splited standard A extension into two new extensions, Zaamo and Zalrsc.
The A extension implies Zaamo and Zalrsc extensions.
Not sure if we need to do the similar check as i and zicsr/zifencei.
==28392== Invalid read of size 1
==28392== at 0x79E97E: lookup_global_or_static_symbol(char const*, block_enum, objfile*, domain_enum) (symtab.h:503)
==28392== by 0x79F859: lookup_global_symbol(char const*, block const*, domain_enum) (symtab.c:2641)
==28392== by 0x79F8E9: language_defn::lookup_symbol_nonlocal(char const*, block const*, domain_enum) const (symtab.c:2473)
==28392== by 0x7A66EE: lookup_symbol_aux(char const*, symbol_name_match_type, block const*, domain_enum, language, field_of_this_result*) (symtab.c:2150)
==28392== by 0x7A68C9: lookup_symbol_in_language(char const*, block const*, domain_enum, language, field_of_this_result*) (symtab.c:1958)
==28392== by 0x7A6A25: lookup_symbol(char const*, block const*, domain_enum, field_of_this_result*) (symtab.c:1970)
==28392== by 0x77120F: select_source_symtab() (source.c:319)
==28392== by 0x7EE2D5: tui_get_begin_asm_address(gdbarch**, unsigned long*) (tui-disasm.c:401)
==28392== by 0x807558: tui_display_main() (tui-winsource.c:55)
==28392== by 0x7937B5: clear_symtab_users(enum_flags<symfile_add_flag>) (functional:2464)
==28392== by 0x794F40: reread_symbols(int) (symfile.c:2690)
==28392== by 0x6497D1: run_command_1(char const*, int, run_how) (infcmd.c:398)
==28392== Address 0x4e67848 is 3,864 bytes inside a block of size 4,064 free'd
==28392== at 0x4A0A430: free (vg_replace_malloc.c:446)
==28392== by 0x936B63: _obstack_free (obstack.c:280)
==28392== by 0x79541E: reread_symbols(int) (symfile.c:2579)
==28392== by 0x6497D1: run_command_1(char const*, int, run_how) (infcmd.c:398)
==28392== by 0x4FFC45: cmd_func(cmd_list_element*, char const*, int) (cli-decode.c:2735)
==28392== by 0x7DAB50: execute_command(char const*, int) (top.c:575)
==28392== by 0x5D2B43: command_handler(char const*) (event-top.c:552)
==28392== by 0x5D3A50: command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) (event-top.c:788)
==28392== by 0x5D1F4B: gdb_rl_callback_handler(char*) (event-top.c:259)
==28392== by 0x857B3F: rl_callback_read_char (callback.c:290)
==28392== by 0x5D215D: gdb_rl_callback_read_char_wrapper_noexcept() (event-top.c:195)
==28392== by 0x5D232F: gdb_rl_callback_read_char_wrapper(void*) (event-top.c:234)
The problem is that tui_display_main is called by the all_objfiles_removed
hook, which tries to access the symbol cache.
This symbol cache is actually stale at this point, and would have been
flushed immediately afterwards by that same all_objfiles_removed hook.
It's not possible to tell the hook to call the observers in a specific
order, but in this case the tui_all_objfiles_removed observer is actually
not needed, since it only calls tui_display_main, and a 'main' can only
be found if objfiles are added, not removed.
So the fix is to simply remove the tui_all_objfiles_removed observer.
The clearing of the source window (if symbols were removed by e.g. 'file'
without arguments) still works, since this is done by the
tui_before_prompt observer.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31697 Approved-By: Tom Tromey <tom@tromey.com>
gdbserver: Clear X86_XSTATE_MPX bits in xcr0 on x32
I worried that there could be other paths that might result in an xcr0
value which has X86_XSTATE_MPX set in x32 mode. As everyone
eventually calls amd64_create_target_description to build their target
description, I figured we could assert in here that if X86_XSTATE_MPX
is set then we should not be an x32 target, this will uncover any
other bugs in this area.
I'm not currently able to build/run any x32 binaries, so I have no way
to test this, but the author of commit 4bb20a6244b7091 did test this
series with that assert in place and didn't see any problems.
Andrew Burgess [Thu, 25 Jan 2024 14:10:42 +0000 (14:10 +0000)]
gdbserver: convert have_ptrace_getregset to a tribool
Convert the have_ptrace_getregset global within gdbserver to a
tribool. This brings the flag into alignment with the corresponding
flag in GDB.
The gdbserver have_ptrace_getregset variable is already used as a
tribool, it just doesn't have the tribool type.
In a future commit I plan to share more code between GDB and
gdbserver, and having this variable be the same type in both code
bases will make the sharing much easier.
There should be no user visible changes after this commit.
Approved-By: John Baldwin <jhb@FreeBSD.org> Reviewed-By: Felix Willgerodt <felix.willgerodt@intel.com>
Andrew Burgess [Tue, 2 Apr 2024 12:42:37 +0000 (13:42 +0100)]
gdbserver/ipa/x86: remove unneeded declarations
Spotted some declarations in gdbserver/linux-amd64-ipa.cc that are no
longer needed. These are:
1. 'init_registers_amd64_linux' - the comment claims this function
is auto generated, but I don't believe that this is still the case.
Also the function is not used in this file,
2. 'tdesc_amd64_linux' - this variable doesn't seem to exist any
more, I suspect this was renamed to 'tdesc_amd64_linux_no_xml', but
neither are used in this file, so lets remove the declaration.
The amd64 in-process-agent still builds fine after this commit.
There should be no user visible changes after this commit.
Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>
Pedro Alves [Tue, 7 May 2024 11:30:39 +0000 (12:30 +0100)]
gdb.base/watchpoint-running.exp: Run sw watch tests even if no hw watch
The code in gdb.base/watchpoint-running.exp that is trying to skip
testing with hardware watchpoints also skips testing with software
watchpoints if hardware watchpoints aren't supported by the target.
This fixes it.
The issue is that the body to execute under the lock is executed in the
context of with_rocm_gpu_lock (uplevel 1 used in with_lock) instead of
in the context of the "original" caller.
This patch adjusted with_rocm_gpu_lock to account for the new extra
frame in the call stack between the caller of with_rocm_gpu_lock and
where the code execution is triggered.
Approved-By: Tom de Vries <tdevries@suse.de>
Change-Id: I79ce2c9615012215867ed5bb60144abe7dce28fe
Lulu Cai [Tue, 23 Apr 2024 07:49:09 +0000 (15:49 +0800)]
LoongArch: Fix ld test failures caused by using instruction aliases
Different versions of objdump may take different forms of output
for instructions. Use -M no-aliases to avoid the failure of ld
test cases caused by objdump using aliases.
projects / thirdparty / binutils-gdb.git / log
