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.
PR 31735
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 407115429b ("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.
PR 31734
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.
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.
Approved-By: John Baldwin <jhb@FreeBSD.org>
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>
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.
Approved-By: John Baldwin <jhb@FreeBSD.org>
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.
Approved-By: John Baldwin <jhb@FreeBSD.org>
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>
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.
Acked-By: John Baldwin <jhb@FreeBSD.org>
If you add an initialization function to a .y file, it will not show
up in init.c, because if the yacc output is in the build tree, it
won't be found.
This patch changes the Makefile to be more robust in this situation.
This removes the current test 'main' from cp-name-parser.y. There
aren't any tests using this, and nowadays it would be better as a unit
test.
Approved-By: John Baldwin <jhb@FreeBSD.org>
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.
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.
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.
This was caused by this commit:
commit 824083f34c
Date: Fri Apr 12 17:47:20 2024 +0100
gdb/doc: use silent-rules.mk in the Makefile
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.
Approved-By: Tom Tromey <tom@tromey.com>
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:
builtin_spawn -ignore SIGHUP gcc -fno-stack-protector \
/tmp/build/gdb/testsuite/outputs/gdb.base/prelink/prelink-lib.c.o \
-fdiagnostics-color=never -shared -g \
-Wl,-soname,prelink.so -Wl,-soname,prelink.so -lm \
-o /tmp/build/gdb/testsuite/outputs/gdb.base/prelink/prelink.so
Notice that '-Wl,-soname,prelink.so' is repeated.
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.
Approved-By: Tom Tromey <tom@tromey.com>
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.
Teested against GCC 13.2 and GCC 15 trunk.
Approved-by: Kevin Buettner <kevinb@redhat.com>
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.
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).
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.
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
...
Fix this by changing the return type to int.
Tested on x86_64-linux.
A recent patch from Andrew pointed out that gdbarch_inner_than returns
'int', while it should really return 'bool'.
Approved-By: Pedro Alves <pedro@palves.net>
This removes tui_refresh_all. There is only a single caller,
tui_refresh_all_win, so inlining the code there simplifies gdb at no
cost.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
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.
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.
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.
I noticed that remote_target::rcmd did not pass its ui_file argument
down to remote_console_output. This patch fixes this oversight.
Tested-By: Ciaran Woodward <ciaranwoodward@xmos.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
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.
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.
Approved-By: Tom Tromey <tom@tromey.com>
Bernd reported that when testing with riscv-unknown-elf target using
the simulator, before commit c7a2ee6491 ("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".
Reported-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Tested-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Change-Id: I48a7afed004a3517b90220674fe5bc856fe7d09a
In commit 2236c5e384 ("[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: 2236c5e384 ("[gdb/python] Make gdb.UnwindInfo.add_saved_register more robust")
The commit c144f63833 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: c144f63833 ("RISC-V: Support B, Zaamo and Zalrsc extensions.")
Approved-By: Tom Tromey <tom@tromey.com>
