| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This adds function types as template parameters in the C++ name
canonicalizer.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11907
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>
|
|
This changes demangle_parse_info to use inline initializers and to
remove some manual memory management.
Approved-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 824083f34c222aa7419e2ea58e82d6f230d5f531
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>
|
|
PR 31738
|
|
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.
|
|
Finally, update the documentation and add a NEWS item.
|
|
Remove the handling of Maverick from BFD. Where appropriate we handle
legacy code by mapping ep9312 onto Armv4t.
|
|
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).
|
|
Remove the decoding of the Maverick flag from readelf.
|
|
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.
|
|
Before removing the code itself, remove the tests that will no-longer
apply.
|
|
|
|
a macro has been invoked.
|
|
|
|
|
|
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.
|
|
This patch removes one of the few DAP "FIXME" comments. This
particular comment is already covered by PR dap/31036.
|
|
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>
|
|
PR 31722
|
|
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".
Reported-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Tested-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Change-Id: I48a7afed004a3517b90220674fe5bc856fe7d09a
|
|
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")
|
|
|
|
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>
|
|
Patch from Tiezhu Yang <yangtiezhu@loongson.cn>.
|
|
Replace the global function address_in_mem_range with the member
function mem_range::contains. The implementation of the function
doesn't change.
There should be no user visible changes after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
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.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
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.
|
|
|
|
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:
ECHO_DVIPS = @echo " DVIPS $@";
ECHO_TEX = @echo " TEX $@";
ECHO_PDFTEX = @echo " PDFTEX $@";
ECHO_TEXI2DVI = @echo " TEXI2DVI $@";
ECHO_MAKEHTML = @echo " MAKEHTML $@";
ECHO_TEXI2POD = @echo " TEXI2POD $@";
ECHO_TEXI2MAN = @echo " TEXI2MAN $@";
ECHO_MAKEINFO = @echo " MAKEINFO $@";
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.
|
