GDB/Python: Make `None' stand for `unlimited' in setting integer parameters
Similarly to booleans and following the fix for PR python/29217 make
`gdb.parameter' accept `None' for `unlimited' with parameters of the
PARAM_UINTEGER, PARAM_INTEGER, and PARAM_ZUINTEGER_UNLIMITED types, as
`None' is already returned by parameters of the two former types, so
one might expect to be able to feed it back. It also makes it possible
to avoid the need to know what the internal integer representation is
for the special setting of `unlimited'.
Expand the testsuite accordingly.
Approved-By: Simon Marchi <simon.marchi@polymtl.ca>
GDB/testsuite: Expand Python integer parameter coverage across all types
Also verify PARAM_UINTEGER, PARAM_INTEGER, and PARAM_ZINTEGER parameter
types, in addition to PARAM_ZUINTEGER and PARAM_ZUINTEGER_UNLIMITED
already covered, and verify a choice of existing GDB parameters. Add
verification for reading parameters via `<parameter>.value' in addition
to `gdb.parameter('<parameter>')' as this covers different code paths.
Approved-By: Simon Marchi <simon.marchi@polymtl.ca>
GDB/Guile: Don't assert that an integer value is boolean
Do not assert that a value intended for an integer parameter, of either
the PARAM_UINTEGER or the PARAM_ZUINTEGER_UNLIMITED type, is boolean,
causing error messages such as:
ERROR: In procedure make-parameter:
ERROR: In procedure gdbscm_make_parameter: Wrong type argument in position 15 (expecting integer or #:unlimited): 3
Error while executing Scheme code.
when initialization with a number is attempted. Instead assert that it
is integer. Keep matching `#:unlimited' keyword as an alternative. Add
suitable test cases.
Approved-By: Simon Marchi <simon.marchi@polymtl.ca>
Tom de Vries [Fri, 21 Oct 2022 06:36:18 +0000 (08:36 +0200)]
[gdb/testsuite] Silence compilation fail in gdb.base/rtld-step.exp
With gcc 7.5.0 and test-case gdb.base/rtld-step.exp, I run into:
...
gdb compile failed, gcc: error: unrecognized command line option \
'-static-pie'; did you mean '-static'?
...
Silence this by checking in the test-case that -static-pie is supported, and
emitting instead:
...
UNTESTED: gdb.base/rtld-step.exp: \
failed to compile (-static-pie not supported or static libc missing)
...
Tested on x86_64-linux, with:
- gcc 7.5.0: UNTESTED
- gcc 12.2.1 with static glibc not installed: UNTESTED
- gcc 12.2.1 with static glibc installed: PASS
Tsukasa OI [Mon, 10 Oct 2022 09:24:48 +0000 (09:24 +0000)]
sim: Remove unused CXXFLAGS substitution
Not only that sim/configure.ac does not AC_SUBST CXXFLAGS,
unless we need C++ compiler like CXX, substitution @CXXFLAGS@ is useless.
Because of this, this commit removes this substitution.
moved AVX-VNNI after AVX512-VNNI, vector Disp8 is applied even when VEX
encoding is selected. Check VEX/EVEX encoding before checking vector
operands to avoid vector Disp8 with VEX encoding.
Andrew Burgess [Wed, 21 Sep 2022 15:23:02 +0000 (16:23 +0100)]
gdb/python: break more dependencies between gdbpy_initialize_* functions
In a later commit in this series I will propose removing all of the
explicit gdbpy_initialize_* calls from python.c and replace these
calls with a more generic mechanism.
One of the side effects of this generic mechanism is that the order in
which the various Python sub-systems within GDB are initialized is no
longer guaranteed.
On the whole I don't think this matters, most of the sub-systems are
independent of each other, though testing did reveal a few places
where we did have dependencies, though I don't think those
dependencies were explicitly documented in comment anywhere.
This commit is similar to the previous one, and fixes the second
dependency issue that I found.
In this case the finish_breakpoint_object_type uses the
breakpoint_object_type as its tp_base, this means that
breakpoint_object_type must have been initialized with a call to
PyType_Ready before finish_breakpoint_object_type can be initialized.
Previously we depended on the ordering of calls to
gdbpy_initialize_breakpoints and gdbpy_initialize_finishbreakpoints in
python.c.
After this commit a new function gdbpy_breakpoint_init_breakpoint_type
exists, this function ensures that breakpoint_object_type has been
initialized, and can be called from any gdbpy_initialize_* function.
I feel that this change makes the dependency explicit, which I think
is a good thing.
There should be no user visible changes after this commit.
Andrew Burgess [Wed, 21 Sep 2022 13:40:30 +0000 (14:40 +0100)]
gdb/python: break dependencies between gdbpy_initialize_* functions
In a later commit in this series I will propose removing all of the
explicit gdbpy_initialize_* calls from python.c and replace these
calls with a more generic mechanism.
One of the side effects of this generic mechanism is that the order in
which the various Python sub-systems within GDB are initialized is no
longer guaranteed.
On the whole I don't think this matters, most of the sub-systems are
independent of each other, though testing did reveal a few places
where we did have dependencies, though I don't think those
dependencies were explicitly documented in a comment anywhere.
This commit removes the first dependency issue, with this and the next
commit, all of the implicit inter-sub-system dependencies will be
replaced by explicit dependencies, which will allow me to, I think,
clean up how the sub-systems are initialized.
The dependency is around the py_insn_type. This type is setup in
gdbpy_initialize_instruction and used in gdbpy_initialize_record.
Rather than depend on the calls to these two functions being in a
particular order, in this commit I propose adding a new function
py_insn_get_insn_type. This function will take care of setting up the
py_insn_type type and calling PyType_Ready. This helper function can
be called from gdbpy_initialize_record and
gdbpy_initialize_instruction, and the py_insn_type will be initialized
just once.
To me this is better, the dependency is now really obvious, but also,
we no longer care in which order gdbpy_initialize_record and
gdbpy_initialize_instruction are called.
There should be no user visible changes after this commit.
Andrew Burgess [Tue, 4 Oct 2022 13:13:53 +0000 (14:13 +0100)]
gdb: some int to bool conversion in breakpoint.c
Some int to bool conversion in breakpoint.c. I've only updated the
function signatures of static functions, but I've updated some
function local variables throughout the file.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Andrew Burgess [Wed, 5 Oct 2022 09:21:02 +0000 (10:21 +0100)]
gdb: make use of scoped_restore in unduplicated_should_be_inserted
I noticed that we could make use of a scoped_restore in the function
unduplicated_should_be_inserted. I've also converted the function
return type from int to bool.
This change shouldn't make any difference, as I don't think anything
within should_be_inserted could throw an exception, but the change
doesn't hurt, and will help keep us safe if anything ever changes in
the future.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Andrew Burgess [Tue, 4 Oct 2022 13:22:25 +0000 (14:22 +0100)]
gdb: used scoped_restore_frame in update_watchpoint
I was doing some int to bool cleanup in update_watchpoint, and I
noticed a manual version of scoped_restore_selected_frame. As always
when these things are done manually, there is the chance that, in an
error case, we might leave the wrong frame selected.
This commit updates things to use scoped_restore_selected_frame, and
also converts a local variable from int to bool.
The only user visible change after this commit is in the case where
update_watchpoint throws an error - we should now correctly restore
the previously selected frame. Otherwise, this commit should be
invisible to the user.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Дилян Палаузов [Thu, 20 Oct 2022 15:05:04 +0000 (17:05 +0200)]
Reapply "Don't build readline/libreadline.a, when --with-system-readline is supplied"
Commit 228cf97dd3c8 ("Merge configure.ac from gcc project") undid the
change originally done in commit 69961a84c9b ("Don't build
readline/libreadline.a, when --with-system-readline is supplied").
Re-apply it.
Jan Beulich [Thu, 20 Oct 2022 08:01:12 +0000 (10:01 +0200)]
x86: re-work AVX-VNNI support
By putting the templates after their AVX512 counterparts, the AVX512
flavors will be picked by default. That way the need to always use {vex}
ceases to exist once respective CPU features (AVX512-VNNI or AVX512VL as
a whole) have been disabled. This way the need for the PseudoVexPrefix
attribute also disappears.
Tom de Vries [Thu, 20 Oct 2022 07:50:04 +0000 (09:50 +0200)]
[gdb/testsuite] Fix gdb.debuginfod/fetch_src_and_symbols.exp with check-read1
With test-case gdb.debuginfod/fetch_src_and_symbols.exp and check-read1, I run
into:
...
(gdb) FAIL: gdb.debuginfod/fetch_src_and_symbols.exp: local_url: \
file fetch_src_and_symbols (got interactive prompt)
...
The problem is that this output:
...
Enable debuginfod for this session? (y or [n]) y^M
...
is matched using regexp "Enable debuginfod?.*" with matches only the first two
words of the output, after which an implicit clause in gdb_test_multiple triggers
on the second part containing the interactive prompt.
Fix this by included the interactive prompt in the regexp.
Tom de Vries [Thu, 20 Oct 2022 07:02:18 +0000 (09:02 +0200)]
[gdb/testsuite] Fix gdb.mi/mi-disassemble.exp with check-read1
With test-case gdb.mi/mi-disassemble.exp and check-read1 I run into:
...
FAIL: gdb.mi/mi-disassemble.exp: disassemble /b main
FAIL: gdb.mi/mi-disassemble.exp: get valueof "*((unsigned char *) 0x400549)"
...
The problem for both FAILs is that the output is parsed using
gdb_test_multiple, which has implicit clauses using $gdb_prompt, which can
match before the explicit clauses using $mi_gdb_prompt.
Fix this by passing -prompt "$mi_gdb_prompt$" to gdb_test_multiple.
It's also been tested (and found to be working) with
RUNTESTFLAGS="CC_FOR_TARGET=clang" on all of the above expect for
Fedora 28. The (old) version of clang available on F28 did not
accept the -static-pie option.
I also tried to make this test work on FreeBSD 13.1. While I think I
made significant progress, I was ultimately stymied by this message
which occurs when attempting to run the main program which has been
set to use the fake/pretend RTLD as the ELF interpreter:
ELF interpreter /path/to/rtld-step-rtld not found, error 22
I have left one of the flags (-static) in place which I believe
to be needed for FreeBSD (though since I never got it to work, I
don't know for sure.) I've also left some declarations needed
for FreeBSD in rtld-step-rtld.c. They're currently disabled via
a #if 0; you'll need to enable them if you want to try to make
it work on FreeBSD.
Kevin Buettner [Thu, 20 Oct 2022 02:36:07 +0000 (19:36 -0700)]
Allow debugging of runtime loader / dynamic linker
At present, GDB does not allow for the debugging of the runtime loader
and/or dynamic linker. Much of the time, this makes sense. An
application programmer doesn't normally want to see symbol resolution
code when stepping into a function that hasn't been resolved yet.
But someone who wishes to debug the runtime loader / dynamic linker
might place a breakpoint in that code and then wish to debug it
as normal. At the moment, this is not possible. Attempting to step
will cause GDB to internally step (and not stop) until code
unrelated to the dynamic linker is reached.
This commit makes a minor change to infrun.c which allows the dynamic
loader / linker to be debugged in the case where a step, next, etc.
is initiated from within that code.
While developing this fix, I tried some approaches which weren't quite
right. The GDB testusite definitely contains tests which FAIL when
it's done incorrectly. (At one point, I saw 17 regressions!) This
commit has been tested on x86-64 linux with no regressions.
Tsukasa OI [Mon, 10 Oct 2022 09:23:16 +0000 (09:23 +0000)]
binutils: Remove unused substitution PROGRAM
Unlike other substitution, this substitution of @PROGRAM@ was done in
binutils/Makefile and it was intended for binutils/cxxfilt.man. @PROGRAM@
in binutils/cxxfilt.man is removed in the commit 0285c67df190 ("Automate
generate on man pages") in 2001 and @PROGRAM@ is ineffective since then.
Because PROGRAM substitution does nothing, removing this manual
substitution should be completely safe.
Tom de Vries [Wed, 19 Oct 2022 15:41:47 +0000 (17:41 +0200)]
[gdb] Fix assert in handle_jit_event
With the cc-with-tweaks.sh patch submitted here (
https://sourceware.org/pipermail/gdb-patches/2022-October/192586.html ) we run
with:
...
$ export STRIP_ARGS_STRIP_DEBUG=--strip-all
$ make check RUNTESTFLAGS="gdb.base/jit-reader.exp \
--target_board cc-with-gnu-debuglink"
...
into the following assert:
...
(gdb) run ^M
Starting program: jit-reader ^M
gdb/jit.c:1247: internal-error: jit_event_handler: \
Assertion `jiter->jiter_data != nullptr' failed.^M
...
Fix this by handling the
jit_bp_sym.objfile->separate_debug_objfile_backlink != nullptr case in
handle_jit_event.
The need to pass in explicit __FILE__/__LINE__ is there probably
because the function predates widespread and portable variadic macros
availability. We can use variadic macros nowadays, and in fact, we
already use them in several places, including the related
gdb_assert_not_reached.
So this patch renames the internal_error function to something else,
and then reimplements internal_error as a variadic macro that expands
__FILE__/__LINE__ itself.
The result is that we now should call internal_error like so:
internal_error ("foo %d", var);
Likewise for internal_warning.
The patch adjusts all calls sites. 99% of the adjustments were done
with a perl/sed script.
The non-mechanical changes are in gdbsupport/errors.h,
gdbsupport/gdb_assert.h, and gdb/gdbarch.py.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: Ia6f372c11550ca876829e8fd85048f4502bdcf06
Andrew Burgess [Wed, 12 Oct 2022 11:46:42 +0000 (12:46 +0100)]
sim/iq2000: silence pointer-sign warnings
When building the iq2000 simulator I see a few warnings like this:
/tmp/build/sim/../../src/sim/iq2000/iq2000.c: In function ‘fetch_str’:
/tmp/build/sim/../../src/sim/iq2000/iq2000.c:50:54: error: pointer targets in passing argument 3 of ‘sim_read’ differ in signedness [-Werror=pointer-sign]
50 | sim_read (CPU_STATE (current_cpu), CPU2DATA(addr), buf, nr);
| ^~~
| |
| char *
I've silenced these warnings by casting buf to 'unsigned char *'.
With this change I now see no warnings when compiling iq2000.c, so
I've removed the line from Makefile.in that disables -Werror.
Makefile.in was also disabling -Werror when compiling mloop.c,
however, I'm not seeing any warnings when compiling that file, so I've
removed the -Werror disable in that case too.
Andrew Burgess [Wed, 12 Oct 2022 10:14:26 +0000 (11:14 +0100)]
sim/ppc: mark device_error function as ATTRIBUTE_NORETURN
The device_error function always ends up calling the error function,
which is itself marked as ATTRIBUTE_NORETURN, so it makes sense that
device_error should also be marked ATTRIBUTE_NORETURN.
Doing this resolves a few warnings from hw_ide.c about possibly
uninitialized variables - the variables are only uninitialized after
passing through a call to device_error, which obviously means the
variables are never really used uninitialized, the simulation will
terminate with the device_error call.
sim/ppc: fixes for arguments to printf style functions
where commit 182421c9d2ee addressed issues with printf format
arguments that were causing the compiler to give an error, this commit
addresses issues that caused the compiler to emit a warning.
This commit is mostly either changing the format string to match the
argument, or in some cases, excess, unused arguments are removed.
Andrew Burgess [Wed, 12 Oct 2022 10:07:24 +0000 (11:07 +0100)]
sim/cgen: mask uninitialized variable warning in cgen-run.c
I see an uninitialized variable warning (with gcc 9.3.1) from
cgen-run.c, like this:
/tmp/build/sim/../../src/sim/cris/../common/cgen-run.c: In function ‘sim_resume’:
/tmp/build/sim/../../src/sim/cris/../common/cgen-run.c:259:5: warning: ‘engine_fns$’ may be used uninitialized in this function [-Wmaybe-uninitialized]
259 | (* engine_fns[next_cpu_nr]) (cpu);
| ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/build/sim/../../src/sim/cris/../common/cgen-run.c:232:14: note: ‘engine_fns$’ was declared here
232 | ENGINE_FN *engine_fns[MAX_NR_PROCESSORS];
| ^~~~~~~~~~
This is a false positive - we over allocate engine_fn, and then only
initialize the nr_cpus entries which we will later go on to use.
However, we can easily silence this warning by initializing the unused
entries in engine_fns to NULL, this might also help if anyone ever
looks at engine_fns in a debugger, it should now be obvious which
entries are in use, and which are not.
With this change the warning is gone.
There should be no change in behaviour with this commit.
Alan Modra [Wed, 19 Oct 2022 08:22:43 +0000 (18:52 +1030)]
Fix addr2line test for ppc64 elfv1 and mingw
* testsuite/binutils-all/addr2line.exp: Tidy. For powerpc64
arrange to pass --synthetic to nm, and extract .main and .fn
symbol address for addr2line test. Handle default executable
extension on cygwin/mingw compilers.
Andrew Burgess [Sun, 2 Oct 2022 14:31:16 +0000 (15:31 +0100)]
gdb/testsuite: avoid temporary file in gdb/testsuite (unittest.exp)
I spotted that the gdb.gdb/unittest.exp script causes a temporary file
inserters_extractors-2.txt to be created in build/gdb/testsuite/
instead of in build/gdb/testsuite/output/gdb.gdb/unittest/.
This is because some of the 'maint selftest' tests create temporary
files in GDB's current directory, specifically, the two source files:
both create a temporary file called inserters_extractors-2.txt, though
we only run the second of these as part of GDB's selftests.
I initially proposed just using GDB's 'cd' command in unittest.exp to
switch to the test output directory before running the selftests,
however, Pedro pointed out that there was a risk here that, if GDB
crashed during shutdown, the generated core file would be left in the
test output directory rather than in the testsuite directory. As a
result, our clever core file spotting logic would fail to spot the
core file and alert the user.
Instead, I propose this slightly more involved solution. I've added a
new with_gdb_cwd directory proc, used like this:
with_gdb_cwd $directory {
# Tests here...
}
The new proc temporarily switches to $directory and then runs the
tests within the block. After running the tests the previous current
working directory is restored.
Additionally, after switching back to the previous cwd, we check that
GDB is still responsive. This means that if GDB crashed immediately
prior to restoring the previous directory, and left the core file in
the wrong place, then the responsiveness check will fail, and a FAIL
will be emitted, this should be enough to alert the user that
something has gone wrong.
With this commit in place the unittest.exp script now leaves its
temporary file in the test output directory.
Andrew Burgess [Sun, 2 Oct 2022 14:18:15 +0000 (15:18 +0100)]
gdb/testsuite: avoid creating files in gdb/testsuite directory
I spotted that the test gdb.dwarf2/dw2-using-debug-str.exp was
creating an output file called debug_str_section in the root
build/gdb/testsuite directory instead of using the
build/gdb/testsuite/output/gdb.dwarf2/dw2-using-debug-str/ directory.
This appears to be caused by a missing '$' character. We setup a
variable debug_str_section which contains a path within the output
directory, but then when we build the objcopy command we use
'debug_str_section' without a '$' prefix, as a result, we create the
debug_str_section file.
This commit adds the missing '$', the file is now created in the
output directory.
It appears that bfd/Makefile.in and bfd/configure were not regenerated
correctly. The differences in the configure file are only whitespace,
but in Makefile.in a critical reference to pe-aarch64.lo was missing.
Andreas Krebbel [Wed, 19 Oct 2022 07:03:17 +0000 (09:03 +0200)]
IBM zSystems: Issue error for *DBL relocs on misaligned symbols
Relocs like PC32DBL require a right shift of the symbol value. There
is no situation where dropping symbol value bits with the right shift
is a good thing. Hence we now issue an error to detect such problems.
Simon Marchi [Tue, 18 Oct 2022 14:17:33 +0000 (10:17 -0400)]
gdb: check for groups with duplicate names in reggroups:add
In the downstream ROCm GDB port, we would create multiple register
groups with duplicate names. While it did not really hurt, it certainly
wasn't the intent. And I don't think it ever makes sense to do so.
To catch these, change the assert in reggroups::add to check for
duplicate names. It's no longer necessary to check for duplicate
reggroup pointers, because adding the same group twice would be caught
by the duplicate name check.
Change-Id: Id216a58acf91f1b314d3cba2d02de73656f8851d Approved-By: Tom Tromey <tom@tromey.com>
Tom Tromey [Sun, 5 Jun 2022 16:22:40 +0000 (10:22 -0600)]
Remove dead code from py-finishbreakpoint.c
PR python/16324 points out that comparing a frame id to null_frame_id
can never succeed, and proposes simply removing the dead code. That
is what this patch does.
Carl Love [Tue, 18 Oct 2022 15:25:36 +0000 (11:25 -0400)]
Update tests to use skip_hw_watchpoint_tests to test for HW watchpoint support.
The hardware watchpoint check has been updated in a couple of recent
patches. This patch updates the hardware watchpoint test in the remaining
gdb tests.
The issue is the PowerPC processors support hardware watchpoints with the
exception of Power 9. The hardware watchpoint support is disabled on
Power 9. The test skip_hw_watchpoint_tests must be used to correctly
determine if the PowerPC processor supports hardware watchpoints.
This patch fixes 6 test failures in test gdb.threads/watchpoint-fork.exp.
Test gdb.base/watch-vfork.exp runs with can-use-hw-watchpoints set to
true and false. When the test is run with can-use-hw-watchpoints set to
true, gdb just falls back to using software watchpoints. The
patch reduces the number of expected passes by 2 since because it now
only runs once with can-use-hw-watchpoints set to false.
Test gdb.mi/mi-watch.exp runs the test with argument hw and sw. If the
argument is hw and hardware watchpoints are not supported the test exits.
The number of expected passes is cut in half with the patch as it now only
runs the test using software breakpoints. Previously the pass to use
hardware watchpoints was not skipped and the test actually ran using
software watchpoints.
The following tests run the same with and without the patch. The tests
are supposed to execute the gdb command "set can-use-hw-watchpoints 0" if
the processor does not support hardware bwatchpoints. However the command
was not being executed and gdb was falling back to using software
watchpoints since the Power 9 watchpoint resource check fails. With the
patch, the tests now execute the command and the test runs using software
watchpoints as it did previously. The tests are:
Tom de Vries [Tue, 18 Oct 2022 13:32:47 +0000 (15:32 +0200)]
[gdb/testsuite] Handle header files with local-remote-host.exp
With test-case gdb.base/included.exp and host board local-remote-host.exp with
tentative fix for PR29697 I run into:
...
included.c:18:10: fatal error: included.h: No such file or directory
#include "included.h"
^~~~~~~~~~~~
compilation terminated.
...
Fix this by adding the missing gdb_remote_download calls.
Tom de Vries [Tue, 18 Oct 2022 13:32:46 +0000 (15:32 +0200)]
[gdb/testsuite] Fix gdb.server/no-thread-db.exp with local-remote-host.exp
With test-case gdb.server/no-thread-db.exp and host board local-remote-host.exp
with a tentative fix for PR29697 I run into:
...
(gdb) print foo^M
Cannot find thread-local storage for Thread 29613.29613, executable file \
$HOME/no-thread-db:^M
Remote target failed to process qGetTLSAddr request^M
(gdb) FAIL: gdb.server/no-thread-db.exp: print foo
...
The regexp in the test-case expects the full $binfile pathname, but we have
instead $HOME/no-thread-db.
Tom de Vries [Tue, 18 Oct 2022 13:32:46 +0000 (15:32 +0200)]
[gdb/testsuite] Fix gdb.server/file-transfer.exp with local-remote-host.exp
When running test-case gdb.server/file-transfer.exp with host
board local-remote-host.exp, I get:
...
Executing on host: cmp -s $outputs/gdb.server/file-transfer/file-transfer \
down-server (timeout = 300)
builtin_spawn [open ...]^M
XYZ2ZYX
FAIL: gdb.server/file-transfer.exp: compare intermediate binary file
...
The remote host and remote target cases are handled here together here in proc
test_file_transfer:
...
if {![is_remote host] && ![is_remote target]} {
set up_server [standard_output_file $up_server]
set down_server [standard_output_file $down_server]
}
...
Tom de Vries [Tue, 18 Oct 2022 13:27:51 +0000 (15:27 +0200)]
[gdb/testsuite] Update boards/README
Update gdb/testsuite/boards/README to reflect recent commit c4c8c27263d
("[gdb/testsuite] Fix host board local-remote-host-notty.exp timeouts"), which
means the board now uses a pseudo-tty, but with editing disabled.
Markus Metzger [Mon, 28 Mar 2022 09:20:10 +0000 (11:20 +0200)]
gdb, solib-svr4: support namespaces in DSO iteration
When looking up names, GDB needs to stay within one linker namespace to
find the correct instance in case the same name is provided in more than
one namespace.
Modify svr4_iterate_over_objfiles_in_search_order() to stay within the
namespace of the current_objfile argument. If no current_objfile is
provided (i.e. it is nullptr), iterate over objfiles in the initial
namespace.
For objfiles that do not have a corresponding so_list to provide the
namespace, assume that the objfile was loaded into the initial namespace.
This would cover the main executable objfile (which is indeed loaded into
the initial namespace) as well as manually added symbol files.
Expected fails:
- gdb.base/non-lazy-array-index.exp: the expression parser may lookup
global symbols, which may result in xfers to read auxv for determining
the debug base as part of svr4_iterate_over_objfiles_in_search_order().
- gdb.server/non-lazy-array-index.exp: symbol lookup may access the
target to read AUXV in order to determine the debug base for SVR4
linker namespaces.
Known issues:
- get_symbol_address() and get_msymbol_address() search objfiles for a
'better' match. This was introduced by
to handle copy relocations but it now causes a wrong address to be
read after symbol lookup actually cound the correct symbol. This can
be seen, for example, with gdb.base/dlmopen.exp when compiled with
clang.
- gnu ifuncs are only looked up in the initial namespace.
- lookup_minimal_symbol() and lookup_minimal_symbol_text() directly
iterate over objfiles and are not aware of linker namespaces.
Markus Metzger [Mon, 30 May 2022 07:35:29 +0000 (09:35 +0200)]
gdb: update gnu ifunc resolve
Update elf_gnu_ifunc_resolve_by_cache() and elf_gnu_ifunc_resolve_by_got()
to use gdbarch_iterate_over_objfiles_in_search_order() in order to
restrict the objfile traversal to the initial namespace.
In order to extend this to other namespaces, we'd need to provide context,
e.g. via an objfile inside that namespace.
There is only one use of find_quick_global_symbol_language that calls it
for the special symbol "main".
Inline the function as it is probably not correct in the general case
where we may have multiple instances of global symbols with the same name
but different languages in different libraries in different linker
namespaces.
Further, change the objfiles iteration into a call to
gdbarch_iterate_over_objfiles_in_search_order, which would only search the
initial linker namespace, where we expect "main" to be located.
Iterate over objfiles in search order using the objfile of the selected
block as current_objfile so the iteration can stay inside the block's
linker namespace.
Markus Metzger [Tue, 12 Apr 2022 14:05:26 +0000 (16:05 +0200)]
gdb, ada: update ada_lookup_simple_minsym
Iterate over objfile in search order using the objfile of the context
block as current_objfile so the iteration can stay inside the block's
linker namespace.
Markus Metzger [Mon, 11 Apr 2022 15:58:23 +0000 (17:58 +0200)]
gdb, ada: collect standard exceptions in all objfiles
When searching for standard exceptions for Ada, we lookup the minimal
symbol of each exception. With linker namespaces there can be multiple
instances in different namespaces. Collect them all.
Markus Metzger [Mon, 11 Apr 2022 14:44:36 +0000 (16:44 +0200)]
gdb, python: use gdbarch_iterate_over_objfiles_in_search_order
The implementation of gdb.lookup_objfile() iterates over all objfiles and
compares their name or build id to the user-provided search string.
This will cause problems when supporting linker namespaces as the first
objfile in any namespace will be found. Instead, use
gdbarch_iterate_over_objfiles_in_search_order to only consider the
namespace of gdb.current_objfile() for the search, which defaults to the
initial namespace when gdb.current_objfile() is None.
Markus Metzger [Mon, 11 Apr 2022 13:12:33 +0000 (15:12 +0200)]
gdb, compile: unlink objfile stored in module
When cleaning up after a compile command, we iterate over all objfiles and
unlink the first objfile with the same name as the one we compiled.
Since we already store a pointer to that objfile in the module and use it
to get the name we're comparing against, there's no reason to iterate, at
all. We can simply use that objfile.
This further avoids potential issues when an objfile with the same name is
loaded into a different linker namespace.
Markus Metzger [Tue, 15 Mar 2022 17:08:06 +0000 (18:08 +0100)]
gdb, gdbserver: extend RSP to support namespaces
Introduce a new qXfer:libraries-svr4:read annex key/value pair
lmid=<namespace identifier>
to be used together with start and prev to provide the namespace of start
and prev to gdbserver.
Unknown key/value pairs are ignored by gdbserver so no new supports check
is needed.
Introduce a new library-list-svr4 library attribute
lmid
to provide the namespace of a library entry to GDB.
This implementation uses the address of a namespace's r_debug object as
namespace identifier.
This should have incremented the minor version but since unknown XML
attributes are ignored, anyway, and since changing the version results in
a warning from GDB, the version is left at 1.0.
Markus Metzger [Tue, 15 Mar 2022 16:41:13 +0000 (17:41 +0100)]
gdbserver: move main_lm handling into caller
When listing SVR4 shared libraries, special care has to be taken about the
first library in the default namespace as that refers to the main
executable. The load map address of this main executable is provided in
an attribute of the library-list-svr4 element.
Move that code from where we enumerate libraries inside a single namespace
to where we generate the rest of the library-list-svr4 element. This
allows us to complete the library-list-svr4 element inside one function.
Markus Metzger [Mon, 4 Oct 2021 08:24:35 +0000 (10:24 +0200)]
gdb, gdbserver: support dlmopen()
In glibc, the r_debug structure contains (amongst others) the following
fields:
int r_version:
Version number for this protocol. It should be greater than 0.
If r_version is 2, struct r_debug is extended to struct r_debug_extended
with one additional field:
struct r_debug_extended *r_next;
Link to the next r_debug_extended structure. Each r_debug_extended
structure represents a different namespace. The first r_debug_extended
structure is for the default namespace.
1. Change solib_svr4_r_map argument to take the debug base.
2. Add solib_svr4_r_next to find the link map in the next namespace from
the r_next field.
3. Update svr4_current_sos_direct to get the link map in the next namespace
from the r_next field.
4. Don't check shared libraries in other namespaces when updating shared
libraries in a new namespace.
5. Update svr4_same to check the load offset in addition to the name
6. Update svr4_default_sos to also set l_addr_inferior
7. Change the flat solib_list into a per-namespace list using the
namespace's r_debug address to identify the namespace.
Add gdb.base/dlmopen.exp to test this.
To remain backwards compatible with older gdbserver, we reserve the
namespace zero for a flat list of solibs from all namespaces. Subsequent
patches will extend RSP to allow listing libraries grouped by namespace.
Markus Metzger [Fri, 11 Mar 2022 05:46:15 +0000 (06:46 +0100)]
gdb, solib-svr4: remove locate_base()
Whenever we call locate_base(), we clear info->debug_base directly before
the call. Thus, we never cache the base location as locate_base() had
intended.
Move the svr4_have_link_map_offsets() check into elf_locate_base(), inline
locate_base() at all call sites, and remove it.
Jan Beulich [Tue, 18 Oct 2022 06:27:42 +0000 (08:27 +0200)]
x86: generalize gas documentation for disabling of ISA extensions
As of commit ae89daecb132 ("x86: generalize disabling of sub-
architectures") there's no arbitrary subset of ISAs which can also be
disabled. This should have been reflected in documentation right away.
Since I failed to do so, correct this now.
Jan Beulich [Tue, 18 Oct 2022 06:26:56 +0000 (08:26 +0200)]
x86: correct CPU_AMX_{BF16,INT8}_FLAGS
AMX-TILE is a prereq to these, as already correctly expressed by
CPU_ANY_AMX_TILE_FLAGS. Express the dependency also in the reverse
("positive") direction.
Tom Tromey [Mon, 17 Oct 2022 19:16:59 +0000 (13:16 -0600)]
kfail an Ada test for GCC < 12
I noticed one particular Ada test was failing on Fedora 34, but works
when I switch to GCC 12. This patch arranges to kfail the test when
an older compiler is used.
I tested this with GCC 11, 12, and 13. I'm going to check it in.
Pedro Alves [Mon, 17 Oct 2022 16:48:35 +0000 (17:48 +0100)]
gdbarch-components.py: Remove spurious space from "frame_info_ptr " params
If you run gdbarch.py today, you'll get local modifications compared
to what's in the tree, like:
--- c/gdb/gdbarch-gen.h
+++ w/gdb/gdbarch-gen.h
@@ -315,8 +315,8 @@ extern void set_gdbarch_register_type (struct gdbarch *gdbarch, gdbarch_register
should match the address at which the breakpoint was set in the dummy
frame. */
The extra space comes from the "frame_info_ptr " param that appears in
a number of gdbarch methods in gdbarch-components.py. With the extra
space removed, running ./gdbarch.py generates the exact code that's in
the tree already.
Tom Tromey [Thu, 22 Sep 2022 19:10:55 +0000 (13:10 -0600)]
Change .gdb_index de-duplication implementation
While investigating PR symtab/29179, I found that one Ada test failed
because, although a certain symbol was present in the index, with the
new DWARF reader it pointed to a different CU than was chosen by
earlier versions of gdb.
This patch changes how symbol de-duplication is done, deferring the
process until the entire symbol table has been constructed. This way,
it's possible to always choose the lower-numbered CU among duplicates,
which is how gdb (implicitly) previously worked.
Tom Tromey [Thu, 22 Sep 2022 14:43:47 +0000 (08:43 -0600)]
Improve Ada support in .gdb_index
The cooked index work changed how .gdb_index is constructed, and in
the process broke .gdb_index support. This is PR symtab/29179.
This patch partially fixes the problem. It arranges for Ada names to
be encoded in the form expected by the index code. In particular,
linkage names for Ada are emitted, including the "main" name; names
are Ada-encoded; and names are no longer case-folded, something that
prevented operator names from round-tripping correctly.
Tom Tromey [Fri, 14 Oct 2022 13:10:08 +0000 (07:10 -0600)]
Fix regression in c-linkage-name.exp with gdb index
c-linkage-name.exp started failing with the gdb-index target board due
to an earlier patch. The problem here is that some linkage names must
be in the index -- but, based on inspection, not C++ linkage names.
This patch updates the code to exclude only these.
Since "NULL" and "0" are used to represent invalid address in function
"gdbarch_find_by_info" in "binutils-gdb/gdb/arch-utils.c", I modified
them to "nullptr".
Simon Marchi [Wed, 12 Oct 2022 17:32:56 +0000 (13:32 -0400)]
gdb: silence unused-but-set-variable warning about yynerrs in cp-name-parser.y
When building with clang 15 on Ubuntu 20.04, I get:
CXX cp-name-parser.o
cp-name-parser.c.tmp:1777:9: error: variable 'cpnameyynerrs' set but not used [-Werror,-Wunused-but-set-variable]
int yynerrs;
^
/home/smarchi/src/binutils-gdb/gdb/yy-remap.h:58:18: note: expanded from macro 'yynerrs'
#define yynerrs GDB_YY_REMAP (yynerrs)
^
/home/smarchi/src/binutils-gdb/gdb/yy-remap.h:40:29: note: expanded from macro 'GDB_YY_REMAP'
#define GDB_YY_REMAP(YYSYM) GDB_YY_REMAP_1 (GDB_YY_REMAP_PREFIX, YYSYM)
^
/home/smarchi/src/binutils-gdb/gdb/yy-remap.h:39:39: note: expanded from macro 'GDB_YY_REMAP_1'
#define GDB_YY_REMAP_1(PREFIX, YYSYM) GDB_YY_REMAP_2 (PREFIX, YYSYM)
^
/home/smarchi/src/binutils-gdb/gdb/yy-remap.h:38:39: note: expanded from macro 'GDB_YY_REMAP_2'
#define GDB_YY_REMAP_2(PREFIX, YYSYM) PREFIX ## YYSYM
^
<scratch space>:45:1: note: expanded from here
cpnameyynerrs
^
This is because clang 15 warns for something like this:
int n;
n = 0;
++n;
whereas previous versions do not.
yynerrs is defined in yyparse and is there for actions to use. Since
the actions in cp-name-parser.y don't use it, we get a warning. We see
this problem on this particular .y file because it uses `%pure-parser`
[1], which makes yynerrs a local rather than a global.
I initially fixed this by using
DIAGNOSTIC_IGNORE_UNUSED_BUT_SET_VARIABLE (like in commit f7aa1a5acc5
("gold: Suppress "unused" variable warning on Clang")), but then I
realized we could suppress the warning in a more fine-grained way using
this in a rule:
ld/testsuite: consistently add board_ldflags when linking with GCC
Currently, the functions checking if the compiler is available or if a
feature is available add both board_cflags and board_ldflags.
However, functions running the tests only retrieve board_cflags. This
can lead to unexpected errors when mandaratory flags are defined in
board_ldflags and not board_cflags.
ld/ChangeLog:
* testsuite/ld-unique/unique.exp: Add board_ldflags when
linking with GCC.
* testsuite/lib/ld-lib.exp: Likewise.
CaiJingtao [Tue, 11 Oct 2022 01:55:10 +0000 (09:55 +0800)]
Allow explicit size specifier for predicate operand of {sq, uq, }{incp, decp}
Omitting predicate size specifier in vector form of {sq, uq, }{decp, incp} is deprecated and will be prohibited in a future release of the aarch64,
see https://developer.arm.com/documentation/ddi0602/2021-09/SVE-Instructions/DECP--vector---Decrement-vector-by-count-of-true-predicate-elements-.
This allows explicit size specifier, e.g. `decp z0.h, p0.h`, for predicate operand of these SVE instructions.
The existing behaviour of not requiring the specifier is preserved.
And the disasembly is with the specifier with this patch.
The GAS tests passed under our local tests.
opcodes/
* aarch64-asm.c: Modify `sve_size_hsd` encoding.
* aarch64-tbl.h (aarch64_opcode_table): Add QUALS's type OP_SVE_Vv_HSD
for decp, incp, sqdecp, sqincp, uqdecp and uqincp.
gas/
* testsuite/gas/aarch64/sve-movprfx_23.s: Update movprfx_23 testcase's
test_sametwo macro, where take the predicate size specifier.
* testsuite/gas/aarch64/sve-movprfx_23.d: Update movprfx_23 testcase's
expected disassembly.
* testsuite/gas/aarch64/sve-movprfx_23.l: Update movprfx_23 testcase's
expected assembler messages.
* testsuite/gas/aarch64/sve.s: Add sve testcase's instructions for
decp, incp, sqdecp, sqincp, uqdecp and uqincp, which take the
predicate size specifier.
* testsuite/gas/aarch64/sve.d: Update sve testcase's expected
disassembly.
Jan Beulich [Mon, 17 Oct 2022 06:27:32 +0000 (08:27 +0200)]
x86: properly decode EVEX.W for AVX512_4{FMAPS,VNNIW} insns
These require EVEX.W=0. Use %XS to facilitate the checking, even if for
the AVX512_4VNNIW ones this is kind of an abuse (as 's' there stands for
"signed", not "single").
While there also correct the 3rd operand for the AVX512_4VNNIW entries:
Only the memory form is allowed (just like for AVX512_4FMAPS, where the
correct type is already in use).
Jan Beulich [Mon, 17 Oct 2022 06:27:03 +0000 (08:27 +0200)]
x86: fold AVX512-VNNI disassembler entries with AVX-VNNI ones
Make %XV also print the separating blank in the VEX case, while making
it do nothing for EVEX-encoded insns. This way the AVX-VNNI entries
can be re-used for AVX512-VNNI, at the same time fixing the lack of
EVEX.W decoding.
For the AVX-VNNI ones further make sure only VEX.66 forms are actually
decoded.
Tom Tromey [Sat, 24 Sep 2022 19:38:42 +0000 (13:38 -0600)]
More uses of checked_static_cast
This patch changes a few more uses of static_cast to use
checked_static_cast. In this patch, cast-to-references are converted
by moving the dereference outside of the cast, as checked_static_cast
only handles pointers.
Alan Modra [Fri, 14 Oct 2022 01:58:33 +0000 (12:28 +1030)]
PowerPC se_rfmci and VLE, SPE2 and LSP insns with -many
I noticed recently that se_rfmci, a VLE mode instruction, was being
accepted by non-VLE cpus, and also that se_rfmci by itself in a
section did not cause SHF_PPC_VLE to be set. ie. both testcases added
by this patch fail without the changes to tc-ppc.c here.
Also, VLE, SPE2 and LSP insns were not accepted by the assembler with
-many nor were SPE2 and LSP being disassembled with -Many.
gas/
* config/tc-ppc.c (ppc_setup_opcodes): Wrap long lines. Add
vle_opcodes when PPC_OPCODE_VLE or PPC_OPCODE_ANY. Simplify
disassembler index segment checks. Add LSP and SPE2 opcodes
when PPC_OPCODE_ANY too.
(md_assemble): Correct logic adding PPC_APUINFO_VLE and
SHF_PPC_VLE.
* testsuite/gas/ppc/se_rfmci.s
* testsuite/gas/ppc/se_rfmci.d,
* testsuite/gas/ppc/se_rfmci_bad.d: New tests.
* testsuite/gas/ppc/ppc.exp: Run them.
opcodes/
* ppc-dis.c (print_insn_powerpc): Disassemble SPE2 and LSP insn
when -Many.
* ppc-opc.c (vle_opcodes <se_rfmci>): Comment.
Alan Modra [Fri, 14 Oct 2022 11:29:23 +0000 (21:59 +1030)]
zlib-gabi to zstd woes
So we had a zlib-gabi .debug_info section that increased in size with
zstd, so much so that it was better to leave the section
uncompressed. Things went horribly wrong when the section was read
again later. The section was read again off disk using the
uncompressed size. So you get the zlib section again with some
garbage at the end. Fix that particular problem by setting the
section flag SEC_IN_MEMORY. Any future read will get sec->contents.
Also, if the section is to be left uncompressed, the input
SHF_COMPRESSED flag needs to be reset otherwise objcopy will copy it
to output.
Finally, bfd_convert_section_contents needed a small update to handle
zstd compressed sections, and I've deleted bfd_cache_section_contents.
* bfd.c (bfd_convert_section_contents): Handle zstd.
* compress.c (bfd_compress_section_contents): When section
contents are uncompressed set SEC_IN_MEMORY flag,
compress_status to COMRESS_SECTION_NONE, and clear
SHF_COMPRESSED. Set SEC_IN_MEMORY for compressed contents.
(bfd_get_full_section_contents): Don't check section size
against file size when SEC_IN_MEMORY.
(bfd_cache_section_contents): Delete function.
* elf32-arm.c (elf32_arm_get_synthetic_symtab): Expand
bfd_cache_section_contents here.
* bfd-in2.h: Regenerate.
gdb/arm: Don't rely on loop detection to stop unwinding
Setting SP of the next frame to the same address as the current frame
is an ugly way to stop the unwinding. A cleaner way is to rely on
the frame_unwind_stop_reason function to return UNWIND_OUTERMOST.
Tom de Vries [Fri, 14 Oct 2022 19:22:57 +0000 (21:22 +0200)]
[gdb/contrib] Handle STRIP_ARGS_{STRIP,KEEP}_DEBUG in cc-with-tweaks.sh
Handle new environment variable STRIP_ARGS_STRIP_DEBUG, defaulting to
--strip-debug in gdb/contrib/cc-with-tweaks.sh, such that we can easily
reproduce the PR29277 assert using:
...
$ export STRIP_ARGS_STRIP_DEBUG=--strip-all
$ make check RUNTESTFLAGS="gdb.base/jit-reader.exp \
--target_board cc-with-gnu-debuglink"
...
For completeness sake and to avoid confusion about which of the two used strip
invocations the passed args apply to, likewise add STRIP_ARGS_KEEP_DEBUG,
defaulting to --only-keep-debug.
Script checked with shellcheck, no new warnings added.
Tom de Vries [Fri, 14 Oct 2022 19:22:57 +0000 (21:22 +0200)]
[gdb] Fix heap-buffer-overflow in find_program_interpreter
With the test-case included in this patch, we run into:
...
(gdb) target remote localhost:2347^M
`target:twice-connect' has disappeared; keeping its symbols.^M
Remote debugging using localhost:2347^M
warning: Unable to find dynamic linker breakpoint function.^M
GDB will be unable to debug shared library initializers^M
and track explicitly loaded dynamic code.^M
Reading /usr/lib/debug/.build-id/$hex/$hex.debug from remote target...^M
0x00007ffff7dd4550 in ?? ()^M
(gdb) PASS: gdb.server/twice-connect.exp: session=second: gdbserver started
FAIL: gdb.server/twice-connect.exp: found interpreter
...
The problem originates in find_program_interpreter, where
bfd_get_section_contents is called to read .interp, but fails. The function
returns false but the result is ignored, so find_program_interpreter returns
some random string.
Fix this by checking the result of the call to bfd_get_section_contents.
Tom de Vries [Fri, 14 Oct 2022 17:59:26 +0000 (19:59 +0200)]
[gdb/testsuite] Fix gdb.server/unittest.exp with host board local-remote-host.exp
With test-case gdb.server/unittest.exp and host board local-remote-host.exp I
run into:
...
builtin_spawn build/gdbserver/gdbserver --selftest^M
ERROR: : spawn id exp7 not open
while executing
"expect {
-i exp7 -timeout 10
-i $server_spawn_id
-re "Ran ($decimal) unit tests, 0 failed" {
set num_ran $expect_out(1,string)
gdb_assert "..."
("uplevel" body line 1)
invoked from within
"uplevel $body" NONE : spawn id exp7 not open
UNRESOLVED: gdb.server/unittest.exp: unit tests
...
The problem is (as fixed for avr in commit df5b8876083 ("gdb/testsuite: better
handle failures in simavr board, reap simavr process")), that gdb_expect through
remote_expect adds a "-i <gdb spawn id> -timeout 10", which is the one causing
the error.
As in aforementioned commit, fix this by using expect instead.
With test-case gdb.server/stop-reply-no-thread-multi.exp and host board
local-remote-host-notty.exp we occasionally run into a silent out, due to
getting:
...
(gdb) kill^M
(gdb) The program is not being run.^M
...
instead of the expected:
...
(gdb) kill^M
The program is not being run.^M
(gdb)
...
Likewise, we occasionally run into a nonsilent timeout:
...
(gdb) disconnect^M
(gdb) You can't do that when your target is `exec'^M
FAIL: gdb.server/stop-reply-no-thread.exp: to_disable=Tthread: t_nonstop=on: \
disconnect (timeout)
...
Typically, this results in the test-case taking more than two minutes to run.
The problem can be reproduced using just:
...
$ ssh -l $USER 127.0.0.1 gdb -q -ex kill
...
Note that ssh by default uses -T which disables pseudo-tty allocation (as
opposed to -t which forces pseudo-tty allocation):
...
$ ssh -l $USER 127.0.0.1 -T tty
not a tty
$ ssh -l $USER 127.0.0.1 -t tty
/dev/pts/5
Connection to 127.0.0.1 closed.
...
and according to https://stackoverflow.com/a/63241102 the behaviour we're
seeing is specific to using '-T'.
The related host board local-remote-host.exp does use '-t', and the only
difference between the two boards mentioned is whether editing is on or off.
Fix this by:
- moving the content of local-remote-host-notty.exp into
local-remote-host.exp
- consequently, extending the copyright years in local-remote-host.exp
- including local-remote-host.exp in local-remote-host-notty.exp
(making local-remote-host-notty.exp use '-t')
- adding -iex "set editing off" to GDBFLAGS in local-remote-host-notty.exp
This results in the test-case taking just 6 seconds to run.
projects / thirdparty / binutils-gdb.git / log
