Check for
warning: Corrupted shared library list
and for
Invalid cast.
warning: Probes-based dynamic linker interface failed.
Reverting to original interface.
in gdb_test_multiple.
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.
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. */
-typedef struct frame_id (gdbarch_dummy_id_ftype) (struct gdbarch *gdbarch, frame_info_ptr this_frame);
-extern struct frame_id gdbarch_dummy_id (struct gdbarch *gdbarch, frame_info_ptr this_frame);
+typedef struct frame_id (gdbarch_dummy_id_ftype) (struct gdbarch *gdbarch, frame_info_ptr this_frame);
+extern struct frame_id gdbarch_dummy_id (struct gdbarch *gdbarch, frame_info_ptr this_frame);
extern void set_gdbarch_dummy_id (struct gdbarch *gdbarch, gdbarch_dummy_id_ftype *dummy_id);
etc.
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.
Change-Id: If7d20b8c6b2fd9ff466142a01bd2611c9ef9f53e
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.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29179
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.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29179
The compiler will sometimes emit a linkage name for a type, like:
<1d3> DW_AT_linkage_name: (indirect string, offset: 0x106f): 11__mbstate_t
These names aren't very useful, and this patch changes the DWARF
reader so that they are ignored by the cooked 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".
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 f7aa1a5acc
("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:
(void) yynerrs;
[1] https://www.gnu.org/software/bison/manual/html_node/Error-Reporting-Function.html
Change-Id: I6cae7a4207c19fe1b719e2ac19be69122ebe3af1
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.
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.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
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.
Tested on x86_64-linux.
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.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29652
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 df5b887608 ("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.
Tested on x86_64-linux.
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.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29669
With test-case gdb.server/stop-reply-no-thread.exp and host board
local-remote-host.exp, I run into:
...
Breakpoint 1, ^[[33mmain^[[m () at ^[[32mstop-reply-no-thread.c^[[m:21^M
21 ^[[01;34mreturn^[[m ^[[35m0^[[m^[[31m;^[[m^M
(gdb) FAIL: gdb.server/stop-reply-no-thread.exp: to_disable=: t_nonstop=off: \
continue to main
...
The problem is that styling is enabled, and that is causing a regexp mismatch.
With native, styling is disabled in default_gdb_init by doing
'setenv TERM "dumb"', but that only has effect because the build (where we
execute runtest, and consequently the setenv) and the host (where we execute
gdb) are the same. For this host board however, gdb executes on a remote
host, and the setenv has no effect.
We could try to make some generic way to set TERM on the host, but for the
purposes of this test-case it seems sufficient to just add:
...
set GDBFLAGS "${GDBFLAGS} -iex \"set style enabled off\""
...
so let's go with that for now.
Tested on x86_64-linux.
I looked at all the spots using value_mark, and converted all the
straightforward ones to use scoped_value_mark instead.
Regression tested on x86-64 Fedora 34.
When it's impossible to read the FPCCR and XPSR, the unwinding is
unpredictable as the it's not possible to determine the correct
frame size or padding.
The only sane thing to do in this condition is to stop the unwinding.
Example session without this patch:
(gdb) bt
#0 SVC_Handler () at .../GPIO/GPIO_EXTI/Src/stm32f4xx_it.c:112
.../gdb/arm-tdep.c:3594: internal-error: arm_m_exception_cache: Assertion `safe_read_memory_unsigned_integer (FPCCR, ARM_INT_REGISTER_SIZE, byte_order, &fpccr)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
0x5583bfb2a157 gdb_internal_backtrace_1
...
---------------------
This is a bug, please report it. For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.
Aborted (core dumped)
Example session with this patch:
(gdb) bt
#0 SVC_Handler () at .../GPIO/GPIO_EXTI/Src/stm32f4xx_it.c:112
warning: Could not fetch required FPCCR content. Further unwind is impossible.
#1 <signal handler called>
(gdb)
Reviewed-by: Pedro Alves <pedro@palves.net>
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
I noticed in gdb.base/skip-solib.exp:
...
if {[gdb_compile_shlib ${srcdir}/${subdir}/${srcfile_lib} ${binfile_lib} \
[list debug -Wl,-soname,${libname}.so]] != ""} {
return -1
}
...
that the -Wl,-soname argument is missing an ldflags= prefix, but adding it
gives us a duplicate:
...
Executing on host: gcc -fno-stack-protector \
outputs/gdb.base/skip-solib/skip-solib-lib.c.o -fdiagnostics-color=never \
-shared -g -Wl,-soname,libskip-solib.so -Wl,-soname,libskip-solib.so -lm \
-o outputs/gdb.base/skip-solib/libskip-solib.so (timeout = 300)
...
so apparently it's taken care of by gdb_compile_shlib.
Drop the inactive and also unnecessary -Wl,-soname,${libname}.so from the
flags list for the gdb_compile_shlib call.
Tested on x86_64-linux.
With test-case gdb.base/infoline-reloc-main-from-zero.exp and target board
unix/-fPIE/-pie I run into:
...
gdb compile failed, ld: infoline-reloc-main-from-zero: error: \
PHDR segment not covered by LOAD segment
collect2: error: ld returned 1 exit status
...
When running with native, I find that the executable is static:
...
$ file infoline-reloc-main-from-zero
infoline-reloc-main-from-zero: ELF 64-bit LSB executable, x86-64, \
version 1 (SYSV), statically linked, BuildID[sha1]=$hex, with debug_info, \
not stripped
...
despite not having been compiled with -static.
Fix the compilation by adding -static to the compilation flags.
Tested on x86_64-linux.
Compilers default to either PIE or no-PIE executables.
In order to test PIE executables with a compiler that produces non-PIE by
default, we can use target board unix/-fPIE/-pie, which set the multilib_flags
of the target board to "-fPIE -pie".
Likewise, we can use target board unix/-fno-PIE/-no-pie with a compiler that
produces PIE by default.
The target board unix/-fno-PIE/-no-pie has a potential problem when compiling
shared libs, because the multilib_flags will override the attempts of
gdb_compile_shlib to compile with -fPIC. This is taken care of by running the
body of gdb_compile_shlib wrapped in with_PIE_multilib_flags_filtered.
The target board unix/-fPIE/-pie has a problem with nopie compilations. The
current approach is to do the compilation hoping for the best, and if we find
out that the resulting executable is PIE despite specifying nopie, we error
out with the standard error message "nopie failed to prevent PIE executable".
That however does not work for hard-coded assembly nopie test-cases, which will
just noisily refuse to compile:
...
ld: amd64-disp-step0.o: relocation R_X86_64_32S against `.text' can not be \
used when making a PIE object; recompile with -fPIE^M
...
Fix this in gdb_compile by filtering out the PIE settings in the target board
multilib_flags when pie or nopie is specified.
Tested on x86_64-linux.
Add a new proc cond_wrap, that can be used to replace the repetitive:
...
if { $cond } {
wrap {
<body>
}
} else {
<body>
}
...
with the shorter:
...
cond_wrap $cond wrap {
<body>
}
...
Tested on x86_64-linux.
Test gdb.base/watchpoint.exp generates 4 test errors on Power 9. The
test uses the test [target_info exists gdb,no_hardware_watchpoints] to
determine if the processor supports hardware watchpoints. The check
only examines the processor type to determine if it supports hardware
watchpoints.
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 replaces the [target_info exists gdb,no_hardware_watchpoints]
with the skip_hw_watchpoint_tests_p check. With the patch, the test runs
on Power 9 with hardware watchpoint force-disabled. The test runs on
all other PowerPC processors with and without hardware watchpoints
enabled.
The patch has been tested on Power 9 to verify the test only runs with
hardware breakpoints disabled. The patch has been tested on X86-64 with
no regression failures. The test fails on Power 10 due to an internal GDB
error due to resource management. The resource management issue will be
addressed in another patch.
With test-case gdb.dwarf2/macro-source-path.exp and target board unix/-m32, I
run into:
...
as: macro-source-path-gcc11-ld238-dw5-filename-641.o: \
unsupported relocation type: 0x1^M
...
The problem is that we have 64-bit dwarf so the debug_line offset in the
.debug_macro section is an 8-byte entity, emitted using ".8byte":
...
.section .debug_macro
.Lcu_macros4:
.2byte 5 /* version */
.byte 3 /* flags */
.8byte .LLlines3 /* debug_line offset */
...
but the linker doesn't support 8-byte relocation types on a 32-bit architecture.
This is similar to what was fixed in commit a5ac8e7fa3
("[gdb/testsuite] Fix 64-bit dwarf test-cases with -m32") for for instance
.debug_abbrev.
Fix this in the same way, by using _op_offset to emit the debug_line offset.
Tested on x86_64-linux with native and target board unix/-m32.
With test-case gdb.dwarf2/entry-value-typedef.exp and target board unix/-m32,
I run into:
...
builtin_spawn -ignore SIGHUP g++ -fno-stack-protector \
gdb/testsuite/gdb.dwarf2/entry-value-typedef-amd64.S \
-fdiagnostics-color=never -Lbuild/libiberty -lm -m32 \
-o outputs/gdb.dwarf2/entry-value-typedef/entry-value-typedef^M
entry-value-typedef.cpp: Assembler messages:^M
entry-value-typedef.cpp:38: Error: bad register name `%rbp'^M
...
The problem is that the test-cases selects an amd64 .S file based on the check:
...
if { [istarget "x86_64-*-linux*"] } {
...
which is also true for target board unix/-m32 on x86_64-linux.
Fix this by adding the missing is_lp64_target check.
Tested on x86_64-linux, using native and target board unix/-m32.
With target board unix/-m32 and test-case gdb.mi/mi-disassemble.exp we have:
...
(gdb) ^M
print/x *((unsigned char *) 0x8048485)^M
&"print/x *((unsigned char *) 0x8048485)\n"^M
~"$9 = 0x83\n"^M
^done^M
(gdb) ^M
PASS: gdb.mi/mi-disassemble.exp: get valueof "*((unsigned char *) 0x8048485)"
FAIL: gdb.mi/mi-disassemble.exp: byte at 0x8048485 matches
...
The test-case passes with native.
With native we see in gdb.log that variable longest_insn_bytes is:
...
Longest instruction at 0x0000000000400549 with bytes '48 8b 05 20 01 00 00'
...
and variable split_bytes (added debug puts) ends up as:
...
SPLIT_BYTES: 48 8b 05 20 01 00 00
...
But with unix/-m32 we have longest_insn_byte:
...
Longest instruction at 0x08048481 with bytes '8d 4c 24 04 '
...
and split_bytes ends up as:
...
SPLIT_BYTES: 8d 4c 24 04 {} {} {} {} {} {} {} {}
...
so the trailing whitespace is translated by split to empty bytes, and the
mismatch FAILs are generated for those.
Fix this by stripping the whitespace, which makes us end up with a different
and indeed longer insn:
...
Longest instruction at 0x08048492 with bytes 'dd 05 98 85 04 08'
...
Tested on x86_64-linux, with native and target board unix/-m32.
Test gdb.base/watchpoint-stops-at-right-insn.exp generates 4 test errors
on Power 9. The test uses the test [target_info exists gdb,
no_hardware_watchpoints] to determine if the processor supports hardware
watchpoints. The check only examines the processor type to determine if
it supports hardware watchpoints. Note, the test works fine on Power 10.
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 replaces the [target_info exists gdb,no_hardware_watchpoints]
with the skip_hw_watchpoint_tests_p check. With the patch, the test is
disabled on Power 9 but runs on all other PowerPC processors.
The patch has been tested on Power 9, Power 10 and X86-64 with no
regression failures.
When running test-case gdb.base/ctf-constvars.exp on openSUSE Tumbleweed (with
system gcc version 12, providing gcc -gctf support, enabling the ctf test-cases
in the gdb testsuite), I run into:
...
(gdb) print vox^M
'vox' has unknown type; cast it to its declared type^M
(gdb) FAIL: gdb.base/ctf-constvars.exp: print vox
...
There are two causes for this:
- the linker flags are missing --ctf-variables, so the information for variable
vox is missing (reported in PR29468), and
- the executable contains some dwarf2 due to some linked-in glibc objects,
so the ctf info is ignored (reported in PR29160).
By using:
- -Wl,--ctf-variable,
- -Wl,--strip-debug, and
we can make the test-case and some similar test-cases pass.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29160
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29468
When running test-case gdb.base/gdbindex-stabs.exp on openSUSE Tumbleweed (with
gcc 12) I get:
...
gdb compile failed, gdb/testsuite/gdb.base/gdbindex-stabs.c: warning: \
STABS debugging information is obsolete and not supported anymore
...
Silence the warning by passing quiet to gdb_compile. Likewise in two other
test-cases.
With test-cases gdb.base/cvexpr.exp and gdb.base/whatis.exp I run into:
...
gdb compile failed, gcc: error: unrecognized debug output level 't'
...
This is due to using additional_flags=-gt.
Commit ffb3f58793 ("CTF: multi-CU and archive support") replaced
additional_flags=-gt with additional_flags=-gctf in gdb.ctf/*.exp and
gdb.base/ctf-*.exp.
Do the same in these two test-cases.
Tested on x86_64-linux.
On openSUSE Tumbleweed (with ld 2.39) and test-case
gdb.base/infoline-reloc-main-from-zero.exp, I get:
...
gdb compile failed, ld: warning: infoline-reloc-main-from-zero has a LOAD \
segment with RWX permissions
UNTESTED: gdb.base/infoline-reloc-main-from-zero.exp: \
infoline-reloc-main-from-zero.exp
...
Fix this by compiling with -Wl,--no-warn-rwx-segments.
Tested on x86_64-linux.
On openSUSE Tumbleweed (with ld 2.39) I get for test-case
gdb.base/nested-subp2.exp:
...
gdb compile failed, ld: warning: tmp.o: requires executable stack \
(because the .note.GNU-stack section is executable)
...
Fix this by compiling with -Wl,--no-warn-execstack.
Likewise in gdb.base/nested-subp3.exp
Tested on x86_64-linux.
On openSUSE Tumbleweed I noticed:
...
UNTESTED: gdb.dwarf2/fission-absolute-dwo.exp: fission-absolute-dwo.exp
ERROR: failed to compile fission-absolute-dwo
...
The ERROR is unnecessary, given that an UNTESTED is already emitted.
Furthermore, it could be argued that it is incorrect because it's not a
testsuite error to not be able to compile something, and UNTESTED or
UNSUPPORTED is more appropriate.
Remove the perror call, likewise in fission-relative-dwo.exp.
Tested on x86_64-linux.
I noticed that the $want_gnu_debuglink code in gdb/contrib/cc-with-tweaks.sh
uses objcopy instead of $OBJCOPY. Fix this.
Script checked with shellcheck, no new warnings added.
Tested on x86_64-linux.
Having two overloads of target_read_auxv that don't have the same goals
is confusing. Rename the one that reads from an explicit target_ops to
target_read_auxv_raw. Also, it occured to me that the non-raw version
could use the raw version, that reduces duplication a bit.
Change-Id: I28e5f7cecbfcacd0174d4686efb3e4a23b4ad491
There's a flaw in the interaction of the auxv caching and the fact that
target_auxv_search allows reading auxv from an arbitrary target_ops
(passed in as a parameter). This has consequences as explained in this
thread:
https://inbox.sourceware.org/gdb-patches/20220719144542.1478037-1-luis.machado@arm.com/
In summary, when loading an AArch64 core file with MTE support by
passing the executable and core file names directly to GDB, we see the
MTE info:
$ ./gdb -nx --data-directory=data-directory -q aarch64-mte-gcore aarch64-mte-gcore.core
...
Program terminated with signal SIGSEGV, Segmentation fault
Memory tag violation while accessing address 0x0000ffff8ef5e000
Allocation tag 0x1
Logical tag 0x0.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
But if we do it as two separate commands (file and core) we don't:
$ ./gdb -nx --data-directory=data-directory -q -ex "file aarch64-mte-gcore" -ex "core aarch64-mte-gcore.core"
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
The problem with the latter is that auxv data gets improperly cached
between the two commands. When executing the file command, auxv gets
first queried here, when loading the executable:
#0 target_auxv_search (ops=0x55555b842400 <exec_ops>, match=0x9, valp=0x7fffffffc5d0) at /home/simark/src/binutils-gdb/gdb/auxv.c:383
#1 0x0000555557e576f2 in svr4_exec_displacement (displacementp=0x7fffffffc8c0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2482
#2 0x0000555557e594d1 in svr4_relocate_main_executable () at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2878
#3 0x0000555557e5989e in svr4_solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2933
#4 0x0000555557e6e49f in solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib.c:1253
#5 0x0000555557f33e29 in symbol_file_command (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/symfile.c:1655
#6 0x00005555573319c3 in file_command (arg=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:555
#7 0x0000555556e47185 in do_simple_func (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1, c=0x612000047740) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:95
#8 0x0000555556e551c9 in cmd_func (cmd=0x612000047740, args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2543
#9 0x00005555580e63fd in execute_command (p=0x7fffffffe02c "e", from_tty=1) at /home/simark/src/binutils-gdb/gdb/top.c:692
#10 0x0000555557771913 in catch_command_errors (command=0x5555580e55ad <execute_command(char const*, int)>, arg=0x7fffffffe017 "file aarch64-mte-gcore", from_tty=1, do_bp_actions=true) at /home/simark/src/binutils-gdb/gdb/main.c:513
#11 0x0000555557771fba in execute_cmdargs (cmdarg_vec=0x7fffffffd570, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd230) at /home/simark/src/binutils-gdb/gdb/main.c:608
#12 0x00005555577755ac in captured_main_1 (context=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1299
#13 0x0000555557775c2d in captured_main (data=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1320
#14 0x0000555557775cc2 in gdb_main (args=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1345
#15 0x00005555568bdcbe in main (argc=10, argv=0x7fffffffdba8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
Here, target_auxv_search is called on the inferior's target stack. The
target stack only contains the exec target, so the query returns empty
auxv data. This gets cached for that inferior in `auxv_inferior_data`.
In its constructor (before it is pushed to the inferior's target stack),
the core_target needs to identify the right target description from the
core, and for that asks the gdbarch to read a target description from
the core file. Because some implementations of
gdbarch_core_read_description (such as AArch64's) need to read auxv data
from the core in order to determine the right target description, the
core_target passes a pointer to itself, allowing implementations to call
target_auxv_search it. However, because we have previously cached
(empty) auxv data for that inferior, target_auxv_search searched that
cached (empty) auxv data, not auxv data read from the core. Remember
that this data was obtained by reading auxv on the inferior's target
stack, which only contained an exec target.
The problem I see is that while target_auxv_search offers the
flexibility of reading from an arbitrary (passed as an argument) target,
the caching doesn't do the distinction of which target is being queried,
and where the cached data came from. So, you could read auxv from a
target A, it gets cached, then you try to read auxv from a target B, and
it returns the cached data from target A. That sounds wrong. In our
case, we expect to read different auxv data from the core target than
what we have read from the target stack earlier, so it doesn't make
sense to hit the cache in this case.
To fix this, I propose splitting the code paths that read auxv data from
an inferior's target stack and those that read from a passed-in target.
The code path that reads from the target stack will keep caching,
whereas the one that reads from a passed-in target won't. And since,
searching in auxv data is independent from where this data came from,
split the "read" part from the "search" part.
From what I understand, auxv caching was introduced mostly to reduce
latency on remote connections, when doing many queries. With the change
I propose, only the queries done while constructing the core_target
end up not using cached auxv data. This is fine, because there are just
a handful of queries max, done at this point, and reading core files is
local.
The changes to auxv functions are:
- Introduce 2 target_read_auxv functions. One reads from an explicit
target_ops and doesn't do caching (to be used in
gdbarch_core_read_description context). The other takes no argument,
reads from the current inferior's target stack (it looks just like a
standard target function wrapper) and does caching.
The first target_read_auxv actually replaces get_auxv_inferior_data,
since it became a trivial wrapper around it.
- Change the existing target_auxv_search to not read auxv data from the
target, but to accept it as a parameter (a gdb::byte_vector). This
function doesn't care where the data came from, it just searches in
it. It still needs to take a target_ops and gdbarch to know how to
parse auxv entries.
- Add a convenience target_auxv_search overload that reads auxv
data from the inferior's target stack and searches in it. This
overload is useful to replace the exist target_auxv_search calls that
passed the `current_inferior ()->top_target ()` target and keep the
call sites short.
- Modify parse_auxv to accept a target_ops and gdbarch to use for
parsing entries. Not strictly related to the rest of this change,
but it seems like a good change in the context.
Changes in architecture-specific files (tdep and nat):
- In linux-tdep, linux_get_hwcap and linux_get_hwcap2 get split in two,
similar to target_auxv_search. One version receives auxv data,
target and arch as parameters. The other gets everything from the
current inferior. The latter is for convenience, to avoid making
call sites too ugly.
- Call sites of linux_get_hwcap and linux_get_hwcap2 are adjusted to
use either of the new versions. The call sites in
gdbarch_core_read_description context explicitly read auxv data from
the passed-in target and call the linux_get_hwcap{,2} function with
parameters. Other call sites use the versions without parameters.
- Same idea for arm_fbsd_read_description_auxv.
- Call sites of target_auxv_search that passed
`current_inferior ()->top_target ()` are changed to use the
target_auxv_search overload that works in the current inferior.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Change-Id: Ib775a220cf1e76443fb7da2fdff8fc631128fe66
When running test-case gdb.debuginfod/fetch_src_and_symbols.exp with target
board native-gdbserver, I get:
...
Running gdb.debuginfod/fetch_src_and_symbols.exp ...
ERROR: tcl error sourcing gdb.debuginfod/fetch_src_and_symbols.exp.
ERROR: gdbserver does not support start without extended-remote
while executing
"error "gdbserver does not support $command without extended-remote""
(procedure "gdb_test_multiple" line 51)
invoked from within
"gdb_test_multiple $command $message {*}$opts $user_code"
(procedure "gdb_test" line 56)
invoked from within
"gdb_test "start" "Temporary breakpoint.*""
...
Fix this by replacing gdb_test "start" with runto_main.
Tested on x86_64-linux.
The python black formatter was complaining about formatting on the
script gdb.python/pretty-print-call-by-hand.py. This commit changed
the offending lines to make the formatter happy.
I noticed in capture_command_output that the output of a single command is
matched using two gdb_test_multiples:
- the first one matching the echoed command and skipping an optional prefix,
- the second one matching the output and the prompt.
This is error-prone, because the first gdb_test_multiple has implicit
clauses which may consume the prompt.
The problem is easy to spot with an example. First consider:
...
set output [capture_command_output "print 1" "\\\$1 = "]
gdb_assert { [string equal $output "1"] }
...
for which we get:
...
PASS: [string equal $output "1"]
...
If we change the prefix string to a no-match, say "1 = ", and update the
output string match accordingly, we get instead:
...
FAIL: capture_command_output for print 1
FAIL: [string equal $output "\$1 = 1"]
...
The first FAIL is produced by the first gdb_test_multiple, consuming the prompt.
The second gdb_test_multiple then silently times out waiting for another prompt,
after which the second FAIL is produced. Note that the timeout is silent
because the gdb_test_multiple is called with an empty message argument.
The second FAIL is because capture_command_output returns "", given that all
the command output was consumed by the first gdb_test_multiple.
Fix this by rewriting capture_command_output to use only a single
gdb_test_multiple.
Tested on x86_64-linux.
I see some random failures in this test:
FAIL: gdb.base/async-shell.exp: run & (timeout)
It can be reliably reproduced on a recent enough GNU/Linux with this
change:
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 44cc28b30051..2a3c8253ba5a 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -1301,6 +1301,7 @@ proc gdb_test_multiple { command message args } {
}
set gdb_test_name "$message"
+ sleep 2
set result 0
set code [catch {gdb_expect $code} string]
"recent enough" means a system where libpthread.so was merged with
libc.so, so at least glibc 2.34.
The problem is that the `run &` command prints some things after the
prompt:
(gdb) [Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
If expect is quick enough, it will consume only up to the prompt. But
if it is slow enough, it will consume those messages at the same time as
the prompt, in which case the gdb_test used for "run &" won't match. By
default, the prompt used by gdb_test uses a `$` to anchor the match at
the end of the buffer. If there's anything following the prompt, it
won't match.
The diff above adds a delay between sending the command and consuming
the output, giving GDB more time to output the messages, giving a good
chance that expect consumes them at the same time as the prompt.
This is normally handled by using gdb_test_multiple and specifying a
pattern that ends with "$gdb_prompt", but not a trailing $. I think
this is common enough that it deserves its own gdb_test option.
Therefore, add the -no-anchor-prompt option to gdb_test, and
gdb_test_no_output for completeness. Use it in
gdb.base/async-shell.exp.
Change-Id: I9051d8800d1c10a2e95db1a575991f7723492f1b
Approved-By: Tom de Vries <tdevries@suse.de>
print_wchar keeps track of when escape sequences are emitted, to force
an escape sequence if needed by a subsequent character. For example
for the string concatenation "\0" "1", gdb will print "\000\061" --
because printing "\0001" might be confusing.
However, this code has two errors. First, this logic is not needed
for octal escapes, because there is a length limit of 3 for octal
escapes, and gdb always prints these with "%.3o". Second, though,
this *is* needed for hex escapes, because those do not have a length
limit.
This patch fixes these problems and adds the appropriate tests.
print_wchar uses wchar_printable, but this isn't needed -- all the
relevant cases are already handled by the 'switch'. This changes the
code to use gdb_iswprint, and removes a somewhat confusing comment
related to this code.
