The switch to linking with libtool now shows a very long link line
even when V=0. This patch arranges to silence libtool in this
situation.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This patch changes the GDB build system in order to use libtool to
link the several built executables. This makes it possible to refer
to libtool libraries (.la files) in CLIBS.
As an application of the above,
BFD now refers to ../libbfd/libbfd.la
OPCODES now refers to ../opcodes/libopcodes.la
LIBBACKTRACE_LIB now refers to ../libbacktrace/libbacktrace.la
LIBCTF now refers to ../libctf/libctf.la
NOTE1: The addition of libtool adds a few new configure-time options
to GDB. Among these, --enable-shared and --disable-shared, which were
previously ignored. Now GDB shall honor these options when linking,
picking up the right version of the referred libtool libraries
automagically.
NOTE2: I have not tested the insight build.
NOTE3: For regenerating configure I used an environment with Autoconf
2.69 and Automake 1.15.1. This should match the previously
used version as announced in the configure script.
NOTE4: Now the installed shared objects libbfd.so, libopcodes.so and
libctf.so are used by gdb if binutils is installed with
--enable-shared.
Testing performed:
- --enable-shared and --disable-shared (the default in binutils) work
as expected: the linked executables link with the archive or shared
libraries transparently.
- Makefile.in modified for EXEEXT = .exe. It installs the binaries
just fine. The installed gdb.exe runs fine.
- Native build regtested in x86_64. No regressions found.
- Cross build for aarch64-linux-gnu built to exercise
program_transform_name and friends. The installed
aarch64-linux-gnu-gdb runs fine.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29372
Approved-By: Simon Marchi <simon.marchi@efficios.com>
I see failures in this test, due to the function name "add" being too
generic, and unexpected breakpoint locations being found in my
libstdc++, such as (wrapped for readability):
{
number="2.4",enabled="y",addr="0x00007ffff7d67e68",
func="(anonymous namespace)::fast_float::bigint::add",
file="/usr/src/debug/gcc/libstdc++-v3/src/c++17/fast_float/fast_float.h",
fullname="/usr/src/debug/gcc/libstdc++-v3/src/c++17/fast_float/fast_float.h",
line="1815", thread-groups=["i1"]
}
Change the test to use a more unique name.
Change-Id: I91de781be62d246eb41c73eaa410ebdd12633d1d
linux_handle_extended_wait calls target_post_attach if we're handling
a PTRACE_EVENT_CLONE, and libthread_db.so isn't active.
target_post_attach just calls linux_init_ptrace_procfs to set the
lwp's ptrace options. However, this is completely unnecessary,
because, as man ptrace [1] says, options are inherited:
"Flags are inherited by new tracees created and "auto-attached" via
active PTRACE_O_TRACEFORK, PTRACE_O_TRACEVFORK, or PTRACE_O_TRACECLONE
options."
This removes the unnecessary call.
[1] - https://man7.org/linux/man-pages/man2/ptrace.2.html
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I533eaa60b700f7e40760311fc0d344d0b3f19a78
gas uses ZSTD_compressStream2 which is only available with libzstd >=
1.4.0, leading to build errors when an older version is installed.
This patch updates the check libzstd presence to check its version is
>= 1.4.0. However, since gas seems to be the only component requiring
such a recent version this may imply that we disable ZSTD support for
all components although some would still benefit from an older
version.
I ran 'autoreconf -f' in all directories containing a configure.ac
file, using vanilla autoconf-2.69 and automake-1.15.1. I noticed
several errors from autoheader in readline, as well as warnings in
intl, but they are unrelated to this patch.
This should fix some of the buildbots.
OK for trunk?
Thanks,
Christophe
MI version 1 is long since obsolete. Rather than remove it
immediately (though I did send a patch for that), instead let's
deprecate it in GDB 13 and then remove it for GDB 14.
This version of the patch incorporates Simon's warning change, and
Luis' recommendation to mention the gdb versions here.
One test name in gdb.base/dlmopen.exp changes from run to run
since it includes a process id:
PASS: gdb.base/dlmopen.exp: attach 3442682
This is not convenient do diff gdb.sum files to compare test runs.
Fix by using gdb_attach helper function to handle attaching to the
process as it produce a constant test name.
While at it also check gdb_attach's return value to only run the
rest of the test if the attach was successful.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
The mnemonics for the pmxvf16ger*, pmxvf32ger*,pmxvf64ger*, pmxvi4ger8*,
pmxvi8ger4*, and pmxvi16ger2* instructions were officially changed to
pmdmxbf16ger*, pmdmxvf32ger*, pmdmxvf64ger*, pmdmxvi4ger8*, pmdmxvi8ger4*,
pmdmxvi16ger* respectively. The old mnemonics are still supported by the
assembler as extended mnemonics. The disassembler generates the new
mnemonics. The name changes occurred in commit:
commit bb98553cad
Author: Peter Bergner <bergner@linux.ibm.com>
Date: Sat Oct 8 16:19:51 2022 -0500
PowerPC: Add support for RFC02658 - MMA+ Outer-Product Instructions
gas/
* config/tc-ppc.c (md_assemble): Only check for prefix opcodes.
* testsuite/gas/ppc/rfc02658.s: New test.
* testsuite/gas/ppc/rfc02658.d: Likewise.
* testsuite/gas/ppc/ppc.exp: Run it.
opcodes/
* ppc-opc.c (XMSK8, P_GERX4_MASK, P_GERX2_MASK, XX3GERX_MASK): New.
(powerpc_opcodes): Add dmxvi8gerx4pp, dmxvi8gerx4, dmxvf16gerx2pp,
dmxvf16gerx2, dmxvbf16gerx2pp, dmxvf16gerx2np, dmxvbf16gerx2,
dmxvi8gerx4spp, dmxvbf16gerx2np, dmxvf16gerx2pn, dmxvbf16gerx2pn,
dmxvf16gerx2nn, dmxvbf16gerx2nn, pmdmxvi8gerx4pp, pmdmxvi8gerx4,
pmdmxvf16gerx2pp, pmdmxvf16gerx2, pmdmxvbf16gerx2pp, pmdmxvf16gerx2np,
pmdmxvbf16gerx2, pmdmxvi8gerx4spp, pmdmxvbf16gerx2np, pmdmxvf16gerx2pn,
pmdmxvbf16gerx2pn, pmdmxvf16gerx2nn, pmdmxvbf16gerx2nn.
This patch updates the comments in the various gdb files to reflect the
name changes. There are no functional changes made by this patch.
The older instruction names are still used in the test
gdb.reverse/ppc_record_test_isa_3_1.exp for backwards compatibility.
Patch has been tested on Power 10 with no regressions.
The mnemonics for the pmxvf16ger*, pmxvf32ger*,pmxvf64ger*, pmxvi4ger8*,
pmxvi8ger4*, pmxvi16ger2* instructions were officially changed to
pmdmxvf16ger*, pmdmxvf32ger*, pmdmxvf64ger*, pmdmxvi4ger8*, pmdmxvi8ger4*,
pmdmxvi16ger* respectively. The old mnemonics are still supported by the
assembler as extended mnemonics. The disassembler generates the new
mnemonics. The name changes occurred in commit:
commit bb98553cad
Author: Peter Bergner <bergner@linux.ibm.com>
Date: Sat Oct 8 16:19:51 2022 -0500
PowerPC: Add support for RFC02658 - MMA+ Outer-Product Instructions
gas/
* config/tc-ppc.c (md_assemble): Only check for prefix opcodes.
* testsuite/gas/ppc/rfc02658.s: New test.
* testsuite/gas/ppc/rfc02658.d: Likewise.
* testsuite/gas/ppc/ppc.exp: Run it.
opcodes/
* ppc-opc.c (XMSK8, P_GERX4_MASK, P_GERX2_MASK, XX3GERX_MASK): New.
(powerpc_opcodes): Add dmxvi8gerx4pp, dmxvi8gerx4, dmxvf16gerx2pp,
dmxvf16gerx2, dmxvbf16gerx2pp, dmxvf16gerx2np, dmxvbf16gerx2,
dmxvi8gerx4spp, dmxvbf16gerx2np, dmxvf16gerx2pn, dmxvbf16gerx2pn,
dmxvf16gerx2nn, dmxvbf16gerx2nn, pmdmxvi8gerx4pp, pmdmxvi8gerx4,
pmdmxvf16gerx2pp, pmdmxvf16gerx2, pmdmxvbf16gerx2pp, pmdmxvf16gerx2np,
pmdmxvbf16gerx2, pmdmxvi8gerx4spp, pmdmxvbf16gerx2np, pmdmxvf16gerx2pn,
pmdmxvbf16gerx2pn, pmdmxvf16gerx2nn, pmdmxvbf16gerx2nn.
The above commit results in about 224 failures on Power 10 since the
disassembled names do not match the expected names in the test. This
patch updates the expected names in the test to match the values produced
by the disassembler.
This patch updates file gdb.arch/powerpc-power10.exp with the new expected
values to the instructions. The comment giving the name of the instruction
for each binary value in the file gdb.arch/powerpc-power10.c is updated
with the new name. There are no functional changes in file
gdb.arch/powerpc-power10.c.
The test disassembles function foo and searches for the line
"End of assembler dump" to determing the last address in the function. The
assumption is the last instruction will be given right before the line
"End of assembler dump". This assumption fails on PowerPC.
The PowerPC disassembly of the function foo looks like:
Dump of assembler code for function foo:
# => 0x00000000100006dc <+0>: std r31,-8(r1)
# 0x00000000100006e0 <+4>: stdu r1,-48(r1)
# 0x00000000100006e4 <+8>: mr r31,r1
# 0x00000000100006e8 <+12>: nop
# 0x00000000100006ec <+16>: addi r1,r31,48
# 0x00000000100006f0 <+20>: ld r31,-8(r1)
# 0x00000000100006f4 <+24>: blr
# 0x00000000100006f8 <+28>: .long 0x0
# 0x00000000100006fc <+32>: .long 0x0
# 0x0000000010000700 <+36>: .long 0x1000180
# End of assembler dump.
The blr instruction is the last instruction in function foo. The lines
with .long following the blr instruction need to be ignored.
This patch adds a new condition to the gdb_test_multiple "disassemble foo"
test to ignore the lines with the .long.
The patch has been tested on PowerPC and Intel X86-64.
Recent changes to gdb.reverse/step-reverse.exp revealed the latent bug
PR record/29745, where we can't skip one funcion forward if we're using
native-gdbserver. This commit just adds kfails to the test.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29745
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Clang up to version 15 (current) adds macros that were defined in the
command line or by "other means", according to the Dwarf specification,
after the last DW_MACRO_end_file, instead of before the first
DW_MACRO_start_file, as the specification dictates. When GDB reads the
macros after the last file is closed, the macros never end up "in scope"
and so we can't print them. This has been submitted as a bug to Clang
developers (https://github.com/llvm/llvm-project/issues/54506), and PR
macros/29034 was opened for GDB to keep track of this.
Seeing as there is no expected date for it to be fixed, add a workaround
for all current versions of Clang. The workaround detects when
the main file would be closed and if the producer is Clang, and turns
that operation into a noop, so we keep a reference to the current_file
as those macros are read.
A test case was added to confirm the functionality, and the KFAIL for
running gdb.base/macro-source-path when using clang.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29034
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Absent _UNICODE being defined (which gdb's Makefile doesn't do),
windows.h will always define STARTUPINFO is as STARTUPINFOA, so this
cast isn't correct when create_process expects a STARTUPINFOW
parameter (i.e. in a Cygwin build).
Instead write this as &info_ex.StartupInfo (which is always of the
correct type).
A user noticed that TYPE_CODE_FIXED_POINT was not exported by the gdb
Python layer. This patch fixes the bug, and prevents future
occurences of this type of bug.
Currently the resource checking is done if REPARSE is true. The hardware
watchpoint resource checking in update_watchpoint needs to be redone on
each call to function update_watchpoints as the value chain may have
changed. The number of hardware registers needed for a watchpoint can
change if the variable being watched changes. This situation occurs in
this test when watching variable **global_ptr_ptr. Initially when the
watch command is issued, only two addresses need to be watched as
**global_ptr_ptr has not yet been initialized. Once the value of
**global_ptr_ptr is initialized the locations to be tracked increase to
three addresses. However, update_watchpoints is not called again with
REPARSE set to 1 to force the resource checking to be redone. When the
test is run on Power 10, an internal gdb error occurs when the PowerPC
routine tries to setup the three hardware watchpoint address since the hw
only has two hardware watchpoint registers. The error occurs because the
resource checking was not redone in update_watchpoints after
**global_ptr_ptr changed.
The following descibes the situation in detail that occurs on Power 10 with
gdb running on the binary for gdb.base/watchpoint.c.
1 break func4
2 run
3 watch *global_ptr
4 next execute source code: buf[0] = 3;
5 next execute source code: global_ptr = buf;
6 next execute source code: buf[0] = 7;
7 delete 2 (delete watch *global_ptr)
8 watch **global_ptr_ptr
9 next execute source code: buf[1] = 5;
10 next global_ptr_ptr = &global_ptr;
11 next buf[0] = 9;
In step 8, the the watch **global_ptr_prt command calls update_watchpoint
in breakpoint.c with REPARSE set to 1. The function update_watchpoint
calls can_use_hardware_watchpoint to see if there are enough
resources available to add the watchpoint since REPARSE is set to 1. At
this point, **global_ptr_ptr has not been initialized so only two addresses
are watched. The val_chain contains the address for **global_ptr_ptr and 0
since **global_ptr_ptr has not been initialized. The update_watchpoint
updates the breakpoint list as follows:
breakpoint 0
loc 0: b->address = 0x100009c0
breakpoint 1
loc 1: b->address = 0x7ffff7f838a0
breakpoint 2
loc 2: b->address = 0x7ffff7b7fc54
breakpoint 3
loc 3: b->address = 0x7ffff7a5788c
breakpoint 4
loc 4: b->address = 0x0 <-- location pointed to by global_ptr_ptr
loc 5: b->address = 0x100200b8 <-- global_ptr_ptr watchpoint
breakpoint 5
loc 6: b->address = 0x7ffff7b7fc54
In step 10, the next command executes the source code
global_ptr_ptr = &global_ptr. This changes the set of locations to be
watched for the watchpoint **global_ptr_prt. The list of addresses for the
breakpoint consist of the address for global_ptr_prt, global_ptr and buf.
The breakpoint list gets updated by update_watchpoint as follows:
breakpoint 0
loc 0: b->address = 0x100009c0
breakpoint 1
loc 1: b->address = 0x7ffff7f838a0
breakpoint 2
loc 2: b->address = 0x7ffff7b7fc54
breakpoint 3
loc 3: b->address = 0x7ffff7a5788c
breakpoint 4
loc 4: b->address = 0x10020050 buf
loc 5: b->address = 0x100200b0 watch *global_ptr
loc 6: b->address = 0x100200b8 watch **global_ptr_ptr
breakpoint 5
loc 7: b->address = 0x7ffff7b7fc54
breakpoint 6
However, the hardware resource checking was not redone because
update_breakpoint was called with REPARSE equal to 0.
Step 11, execute the third next command. The function
ppc_linux_nat_target::low_prepare_to_resume() attempts a ptrace
call to setup each of the three address for breakpoint 4. The slot
value returned for the third ptrace call is -1 indicating an error
because there are only two hardware watchpoint registers available on
Power 10.
This patch removes just the statement "if (reparse)" in function
update_watchpoint to force the resources to be rechecked on every call to
the function. This ensures that any changes to the val_chain resulting
in needing more resources then available will be caught.
The patch has been tested on Power 8, Power 10 and X86-64. Note the patch
has no effect on Power 9 since hardware watchpoint support is disabled on
that processor.
Test gdb.reverse/pipe-reverse.exp fails on Power 10 running the fedora 36
distro. The gdb record error message is:
Process record and replay target doesn't support syscall number 317.
System call 317 on PowerPC maps to the pipe2 system call.
This patch adds support for the missing pipe2 system call for PowerPC.
Patch fixes the test failure in gdb.reverse/pipe-reverse.exp.
The patch has been tested on Power 10 with no regression failures.
This changes gdbarch to use the "predefault" to initialize its members
inline. This required changing a couple of the Value instantiations
to avoid a use of "gdbarch" during initialization, but on the whole I
think this is better -- it removes a hidden ordering dependency.
PR c++/29243 points out that "info func" on a certain C++ executable
will cause an infinite loop in gdb.
I tracked this down to a bug introduced by commit 6b5a7bc76 ("Handle
member pointers directly in generic_value_print"). Before this
commit, the C++ code to print a member pointer would wind up calling
value_print_scalar_formatted; but afterward it simply calls
generic_value_print and gets into a loop.
This patch restores the previous behavior and adds a regression test.
Clang attempts to minimize the size of the debug-info by not adding
complete information about types that aren't constructed in a given
file. Specifically, this meant that there was minimal information about
class B in the test gdb.cp/converts.exp. To fix this, we just need to
construct any object of type B in that file.
Approved-By: Andrew Burgess <aburgess@redhat.com>
When running gdb.cp/ptype-flags.exp using Clang, we get an unexpected
failure when printing the type of a class with an internal typedef. This
happens because Clang doesn't add accessibility information for typedefs
inside classes (see https://github.com/llvm/llvm-project/issues/57608
for more info). To help with Clang testing, an XFAIL was added to this
test.
When running test-case gdb.server/multi-ui-errors.exp on target board
remote-gdbserver-on-localhost.exp, I run into:
...
(gdb) PASS: gdb.server/multi-ui-errors.exp: connect to gdbserver
continue^M
Continuing.^M
PASS: gdb.server/multi-ui-errors.exp: continue - extra UI
Remote debugging from host ::1, port 35466^M
FAIL: gdb.server/multi-ui-errors.exp: ensure inferior is running
...
The problem is that the target board uses ssh -T, which fails to guarantee
that output from the inferior will be available.
Fix this by copying proc ${board}_spawn from local-remote-host.exp, which
ensures using ssh -t. [ It would be nice to define an ssh base board to
get rid of the copies, but I'm not addressing that in this commit. ]
Likewise for target board remote-stdio-gdbserver.exp.
Tested on x86_64-linux.
With test-case gdb.server/multi-ui-errors.exp and host board
local-remote-host-notty, I run into:
...
(gdb) PASS: gdb.server/multi-ui-errors.exp: interact with GDB's main UI
Executing on target: kill -9 29666 (timeout = 300)
builtin_spawn -ignore SIGHUP kill -9 29666^M
echo^M
Remote connection closed^M
(gdb) (gdb) FAIL: gdb.server/multi-ui-errors.exp: \
main UI, prompt after gdbserver dies (timeout)
...
In contrast, with local-remote-host (so, everything the same but editing off):
...
(gdb) PASS: gdb.server/multi-ui-errors.exp: interact with GDB's main UI
Executing on target: kill -9 31245 (timeout = 300)
builtin_spawn -ignore SIGHUP kill -9 31245^M
Remote connection closed^M
(gdb) echo^M
(gdb) PASS: gdb.server/multi-ui-errors.exp: main UI, prompt after gdbserver dies
...
The test-case issues a kill, which results in a "Remote connection closed"
message and a prompt.
The problem is that the prompt is not consumed, so the subsequent echo may be
issued before that prompt, which causes a mismatch when matching the result
of the echo.
Fix this by consuming the "Remote connection closed" message and prompt.
Tested on x86_64-linux.
With test-case gdb.server/multi-ui-errors.exp we see:
...
(gdb) PASS: multi-ui-errors.exp: main UI, prompt after gdbserver dies
continue^M
Continuing.^M
echo^M
(gdb) PASS: multi-ui-errors.exp: extra UI, prompt after gdbserver dies
...
The continue is issued earlier in the test-case, but the output has not been
consumed, which makes it show up much later.
Consume the continue output asap, to make it clear when the continue is issued:
...
(gdb) PASS: gdb.server/multi-ui-errors.exp: connect to gdbserver
continue^M
Continuing.^M
PASS: gdb.server/multi-ui-errors.exp: continue - extra UI
...
Tested on x86_64-linux.
The usage for board remote-stdio-gdbserver.exp is advertised as:
...
# bash$ make check RUNTESTFLAGS="--target_board=remote-stdio-gdbserver \
# REMOTE_USERNAME=... REMOTE_HOSTNAME=... REMOTE_PORTNUM=... \
# [REMOTE_TMPDIR=${remote_dir}] [GDBSERVER=${remote_gdbserver}]"
...
but when adding REMOTE_PORTNUM=22, I run into:
...
Running stop-reply-no-thread-multi.exp ...
ERROR: tcl error sourcing stop-reply-no-thread-multi.exp.
ERROR: couldn't execute "/usr/bin/ssh -p22": no such file or directory
while executing
"builtin_spawn {/usr/bin/ssh -p22} -l vries localhost {/usr/bin/gdbserver \
--once localhost:2346 \
/home/vries/gdb_versions/devel/build/gdb/testsuite/outp..."
...
Fix this by simply removing REMOTE_PORTNUM.
Tested on x86_64-linux.
In gdb/nat/linux-btrace.c:btrace_this_cpu() we initialize the cpu
structure given to the libipt btrace decoder.
We only consider the extended model field for family 0x6 and forget about
family 0xf and we don't consider the extended family field. Fix it.
I noticed an address in a test name:
...
PASS: gdb.base/eh_return.exp: gdb_breakpoint: \
set breakpoint at *0x000000000040071b
...
Stabilize the test name by using "set breakpoint on address" instead.
Likewise in two other test-cases.
Tested on x86_64-linux.
Propagate fix from commit 17c68d98f7 ("[gdb/testsuite] Disable styling in host
board local-remote-host.exp") to local-remote-host-native.exp.
Tested on x86_64-linux.
I noticed that running test-case gdb.mi/mi-exec-run.exp with host board
local-remote-host.exp takes about 44 seconds.
I found two silent timeouts responsible for this.
The first is in mi_gdb_exit, where we have:
...
if { [is_remote host] && [board_info host exists fileid] } {
send_gdb "999-gdb-exit\n"
gdb_expect 10 {
-re "y or n" {
send_gdb "y\n"
exp_continue
}
-re "Undefined command.*$gdb_prompt $" {
send_gdb "quit\n"
exp_continue
}
-re "DOSEXIT code" { }
}
}
...
so in gdb.log we see:
...
999-gdb-exit^M
999^exit^M
=thread-exited,id="1",group-id="i1"^M
=thread-group-exited,id="i1"^M
...
after which expect just waits for the timeout.
Fix this by adding a gdb_expect clause to parse the exit:
...
-re "\r\n999\\^exit\r\n" { }
...
Note that we're not parsing the thread-exited/thread-group-exited messages, because
they may not be present:
...
$ gdb -i=mi
=thread-group-added,id="i1"
(gdb)
999-gdb-exit
999^exit
$
...
After fixing that, we have:
...
(gdb) ^M
saw mi error
PASS: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: \
force-fail=1: run failure detected
quit^M
&"quit\n"^M
...
What seems to be happening is that default_gdb_exit sends a cli interpreter
quit command to an mi interpreter, after which again expect just waits for the
timeout.
Fix this by adding mi_gdb_exit to the end of the test-case, as in many other
gdb.mi/*.exp test-cases.
After these two fixes, the test-case takes about 4 seconds.
Tested on x86_64-linux.
I build gdb using -O2, and ran the testsuite using taskset -c 0, and ran into:
...
(gdb) PASS: gdb.server/connect-with-no-symbol-file.exp: sysroot=: \
action=delete: setup: adjust sysroot
builtin_spawn gdbserver --once localhost:2385 /connect-with-no-symbol-file^M
/bin/bash: connect-with-no-symbol-file: Permission denied^M
/bin/bash: line 0: exec: connect-with-no-symbol-file: cannot execute: \
Permission denied^M
During startup program exited with code 126.^M
Exiting^M
target remote localhost:2385^M
`connect-with-no-symbol-file' has disappeared; keeping its symbols.^M
localhost:2385: Connection timed out.^M
(gdb) FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=: \
action=delete: connection to GDBserver succeeded
...
The expected series of events is (skipping disconnect and detach as I don't
think they're relevant to the problem):
- enter scenario "permission"
- cp $exec.bak $exec
- gdbserver start with $exec
- chmod 000 $exec
- connect to gdbserver
- enter scenario "delete"
- cp $exec.bak $exec
- gdbserver start with $exec
- delete $exec
- connect to gdbserver
The problem is that the chmod is executed using remote_spawn:
...
} elseif { $action == "permission" } {
remote_spawn target "chmod 000 $target_exec"
}
...
without waiting on the resulting spawn id, so we're not sure when the
chmod will have effect.
The FAIL we're seeing above is explained by the chmod having effect during the
delete scenario, after the "cp $exec.bak $exec" and before the "gdbserver
start with $exec".
Fix this by using remote_exec instead.
Likewise, fix a similar case in gdb.mi/mi-exec-run.exp.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29726
Since commit 90319cefe3 ("GDB/Guile: Don't assert that an integer value
is boolean"), I see:
FAIL: gdb.guile/scm-parameter.exp: kind=PARAM_ZINTEGER: test-PARAM_ZINTEGER-param: guile (set-parameter-value! test-PARAM_ZINTEGER-param #:unlimited)
FAIL: gdb.guile/scm-parameter.exp: kind=PARAM_ZUINTEGER: test-PARAM_ZUINTEGER-param: guile (set-parameter-value! test-PARAM_ZUINTEGER-param #:unlimited)
This comes from the fact that GDB outputs this:
ERROR: In procedure set-parameter-value!:
In procedure gdbscm_set_parameter_value_x: Wrong type argument in position 2 (expecting integer): #:unlimited
Error while executing Scheme code.
while the test expects an additional "ERROR:" on the second line,
something like this:
ERROR: In procedure set-parameter-value!:
ERROR: In procedure gdbscm_set_parameter_value_x: Wrong type argument in position 2 (expecting integer): #:unlimited
Error while executing Scheme code.
Guile 2.0 outputs the `ERROR:` on the second line, while later versions
do not. Change the pattern to accept both outputs. This is similar to
commit 6bbe1a929c ("[gdb/testsuite] Fix gdb.guile/scm-breakpoint.exp
with guile 3.0").
Change-Id: I9dc45e7492a4f08340cad974610242ed689de959
Arm v8-M Architecture Reference Manual,
D1.2.95 EXC_RETURN, Exception Return Payload
describes ES bit:
"ES, bit [0]
Exception Secure. The security domain the exception was taken to.
The possible values of this bit are:
0 Non-secure.
1 Secure"
arm-tdep.c:3443, arm_m_exception_cache () function tests this bit:
exception_domain_is_secure = (bit (lr, 0) == 0);
The test is negated!
Later on line 3553, the condition evaluates if an additional state
context is stacked:
/* With the Security extension, the hardware saves R4..R11 too. */
if (tdep->have_sec_ext && secure_stack_used
&& (!default_callee_register_stacking || exception_domain_is_secure))
RM, B3.19 Exception entry, context stacking
reads:
RPLHM "In a PE with the Security Extension, on taking an exception,
the PE hardware:
...
2. If exception entry requires a transition from Secure state to
Non-secure state, the PE hardware extends the stack frame and also
saves additional state context."
So we should test for !exception_domain_is_secure instead of non-negated
value!
These two bugs compensate each other so unstacking works correctly.
But another test of exception_domain_is_secure (negated due to the
first bug) prevents arm_unwind_secure_frames to work as expected:
/* Unwinding from non-secure to secure can trip security
measures. In order to avoid the debugger being
intrusive, rely on the user to configure the requested
mode. */
if (secure_stack_used && !exception_domain_is_secure
&& !arm_unwind_secure_frames)
Test with GNU gdb (GDB) 13.0.50.20221016-git.
Stopped in a non-secure handler:
(gdb) set arm unwind-secure-frames 0
(gdb) bt
#0 HAL_SYSTICK_Callback () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/NonSecure/Src/nsmain.c:490
#1 0x0804081c in SysTick_Handler ()
at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/NonSecure/Src/nsstm32l5xx_it.c:134
#2 <signal handler called>
#3 HAL_GPIO_ReadPin (GPIOx=0x52020800, GPIO_Pin=8192)
at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Drivers/STM32L5xx_HAL_Driver/Src/stm32l5xx_hal_gpio.c:386
#4 0x0c000338 in SECURE_Mode () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/main.c:86
#5 0x080403f2 in main () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/NonSecure/Src/nsmain.c:278
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
The frames #3 and #4 are secure. backtrace should stop before #3.
Stopped in a secure handler:
(gdb) bt
#0 HAL_SYSTICK_Callback () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/main.c:425
#1 0x0c000b6a in SysTick_Handler ()
at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/stm32l5xx_it.c:234
warning: Non-secure to secure stack unwinding disabled.
#2 <signal handler called>
The exception from secure to secure erroneously stops unwinding. It should
continue as far as the security unlimited backtrace:
(gdb) set arm unwind-secure-frames 1
(gdb) si <-- used to rebuild frame cache after change of unwind-secure-frames
0x0c0008e6 425 if (SecureTimingDelay != 0U)
(gdb) bt
#0 0x0c0008e6 in HAL_SYSTICK_Callback () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/main.c:425
#1 0x0c000b6a in SysTick_Handler ()
at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/stm32l5xx_it.c:234
#2 <signal handler called>
#3 0x0c000328 in SECURE_Mode () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/main.c:88
#4 0x080403f2 in main () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/NonSecure/Src/nsmain.c:278
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Set exception_domain_is_secure to the value expected by its name.
Fix exception_domain_is_secure usage in the additional state context
stacking condition.
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Arm v8-M Architecture Reference Manual,
D1.2.141 IPSR, Interrupt Program Status Register reads
"Exception, bits [8:0]"
9 bits, not 8! It is uncommon but true!
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
In the lockup state the PC value of the the outer frame is irreversibly
lost. The other registers are intact so LR likely contains
PC of some frame next to the outer one, but we cannot analyze
the nearest outer frame without knowing its PC
therefore we do not know SP fixup for this frame.
The frame unwinder possibly gets mad due to the wrong SP value.
To prevent problems terminate unwinding if PC contains the magic
value of the lockup state.
Example session wihtout this change,
Cortex-M33 CPU in lockup, gdb 13.0.50.20221016-git:
----------------
(gdb) c
Continuing.
Program received signal SIGINT, Interrupt.
0xeffffffe in ?? ()
(gdb) bt
#0 0xeffffffe in ?? ()
#1 0x0c000a9c in HardFault_Handler ()
at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/stm32l5xx_it.c:99
#2 0x2002ffd8 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
----------------
The frame #1 is at correct PC taken from LR, #2 is a total nonsense.
With the change:
----------------
(gdb) c
Continuing.
Program received signal SIGINT, Interrupt.
warning: ARM M in lockup state, stack unwinding terminated.
<signal handler called>
(gdb) bt
#0 <signal handler called>
(gdb)
----------------
There is a visible drawback of emitting a warning in a cache buildnig routine
as introduced in Torbjörn SVENSSON's
[PATCH v4] gdb/arm: Stop unwinding on error, but do not assert
The warning is printed just once and not repeated on each backtrace command.
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Should be functionally the same, but uses more pythonic idioms to get
fewer lines of code, and to make sure to not leak open file handles.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This test fails quite reliably for me when ran as:
$ taskset -c 1 make check TESTS="gdb.base/unwind-on-each-insn.exp" RUNTESTFLAGS="--target_board=native-gdbserver"
or more simply:
$ make check-read1 TESTS="gdb.base/unwind-on-each-insn.exp"
The problem is that the gdb_test_multiple call that grabs the frame id
from "maint print frame-id" does not consume the prompt. Well, it does
sometimes due to the trailing .*, but not always. If the prompt is not
consumed, the tests that follow get confused:
FAIL: gdb.base/unwind-on-each-insn.exp: gdb_breakpoint: set breakpoint at *foo
FAIL: gdb.base/unwind-on-each-insn.exp: disassemble foo
FAIL: gdb.base/unwind-on-each-insn.exp: get $sp and frame base in foo: get hexadecimal valueof "$sp"
... many more ...
Use -wrap to make gdb_test_multiple consume the prompt.
While at it, remove the bit that consumes the command name and do
exp_continue, it's not really necessary. And for consistency, do the
same changes to the gdb_test_multiple that consumes the stack address,
although that one was fine, it did consume the prompt explicitly.
Change-Id: I2b7328c8844c7e98921ea494c4c05107162619fc
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
On openSUSE Tumbleweed I run into this for the dwarf assembly test-cases, and
some hardcoded assembly test-cases:
...
Running gdb.dwarf2/fission-absolute-dwo.exp ...
gdb compile failed, ld: warning: fission-absolute-dwo.o: \
missing .note.GNU-stack section implies executable stack
ld: NOTE: This behaviour is deprecated and will be removed in a future \
version of the linker
=== gdb Summary ===
# of untested testcases 1
...
Fix the dwarf assembly test-cases by adding the missing .note.GNU-stack in
proc Dwarf::assemble.
Fix the hard-coded test-cases using this command:
...
$ for f in $(find gdb/testsuite/gdb.* -name *.S); do
if ! grep -q note.GNU-stack $f; then
echo -e "\t.section\t.note.GNU-stack,\"\",@progbits" >> $f;
fi;
done
...
Likewise for .s files, and gdb/testsuite/lib/my-syscalls.S.
The idiom for arm seems to be to use %progbits instead, see commit 9a5911c08b
("gdb/testsuite/gdb.dwarf2: Replace @ with % for ARM compatability"), so
hand-edit gdb/testsuite/gdb.arch/arm-disp-step.S to use %progbits instead.
Note that dwarf assembly testcases use %progbits as decided by proc _section.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29674
Recent commit b2829fcf9b ("[gdb] Fix rethrow exception slicing in
insert_bp_location") introduced macro RETHROW_ON_TARGET_CLOSE_ERROR.
I wrote this as a macro in order to have the rethrowing throw be part of the
same function as the catch, but as it turns out that's not necessary.
Rewrite into a function.
Tested on x86_64-linux.
Commit f34652de0b ("internal_error: remove need to pass
__FILE__/__LINE__") renamed the internal_error function to
internal_error_loc. Change gdb-gdb.gdb.in accordingly.
Change-Id: I876e1623607b6becf74ade53d102ead53a74ed86
The preferred way of rethrowing an exception is by using throw without
expression, because it avoids object slicing of the exception [1].
Fix this in insert_bp_location.
Tested on x86_64-linux.
[1] https://en.cppreference.com/w/cpp/language/throw
Approved-By: Andrew Burgess <aburgess@redhat.com>
The preferred way of rethrowing an exception is by using throw without
expression, because it avoids object slicing of the exception [1].
Fix this in gdb_pretty_print_disassembler::pretty_print_insn.
Tested on x86_64-linux.
[1] https://en.cppreference.com/w/cpp/language/throw
Approved-By: Andrew Burgess <aburgess@redhat.com>
I did a gdb build without python support, and during testing ran into FAILs in
test-case gdb.python/tui-window-names.exp.
Fix this by adding the missing skip_python_test.
Tested on x86_64-linux.
