| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In this commit I propose that we add special handling for the '^' when
used at the start of a gdb_test pattern. Consider this usage:
gdb_test "some_command" "^command output pattern"
I think the intention here is pretty clear - run 'some_command', and
the output from the command should be exactly 'command output
pattern'.
After the previous commit which tightened up how gdb_test matches the
final newline and prompt we know that the only thing after the output
pattern will be a single newline and prompt, and the leading '^'
ensures that there's no output before 'command output pattern', so
this will do what I want, right?
... except it doesn't. The command itself will also needs to be
matched, so I should really write:
gdb_test "some_command" "^some_command\r\ncommand output pattern"
which will do what I want, right? Well, that's fine until I change
the command and include some regexp character, then I have to write:
gdb_test "some_command" \
"^[string_to_regexp some_command]\r\ncommand output pattern"
but this all gets a bit verbose, so in most cases I simply don't
bother anchoring the output with a '^', and a quick scan of the
testsuite would indicate that most other folk don't both either.
What I propose is this: the *only* thing that can appear immediately
after the '^' is the command converted into a regexp, so lets do that
automatically, moving the work into gdb_test. Thus, when I write:
gdb_test "some_command" "^command output pattern"
Inside gdb_test we will spot the leading '^' in the pattern, and
inject the regexp version of the command after the '^', followed by a
'\r\n'.
My hope is that given this new ability, folk will be more inclined to
anchor their output patterns when this makes sense to do so. This
should increase our ability to catch any unexpected output from GDB
that appears as a result of running a particular command.
There is one problem case we need to consider, sometime people do
this:
gdb_test "" "^expected output pattern"
In this case no command is sent to GDB, but we are still expecting
some output from GDB. This might be a result of some asynchronous
event for example. As there is no command sent to GDB (from the
gdb_test) there will be no command text to parse.
In this case my proposed new feature injects the command regexp, which
is the empty string (as the command itself is empty), but still
injects the '\r\n' after the command regexp, thus we end up with this
pattern:
^\r\nexpected output pattern
This extra '\r\n' is not what we should expected here, and so there is
a special case inside gdb_test -- if the command is empty then don't
add anything after the '^' character.
There are a bunch of tests that do already use '^' followed by the
command, and these can all be simplified in this commit.
I've tried to run all the tests that I can to check this commit, but I
am certain that there will be some tests that I manage to miss.
Apologies for any regressions this commit causes, hopefully fixing the
regressions will not be too hard.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On amd64 (at least) if a user sets a watchpoint before the inferior
has started then GDB will assume that a hardware watchpoint can be
created.
When the inferior starts there is a chance that the watchpoint can't
actually be create as a hardware watchpoint, in which case (currently)
GDB will silently convert the watchpoint to a software watchpoint.
Here's an example session:
(gdb) p sizeof var
$1 = 4000
(gdb) watch var
Hardware watchpoint 1: var
(gdb) info watchpoints
Num Type Disp Enb Address What
1 hw watchpoint keep y var
(gdb) starti
Starting program: /home/andrew/tmp/watch
Program stopped.
0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) info watchpoints
Num Type Disp Enb Address What
1 watchpoint keep y var
(gdb)
Notice that before the `starti` command the watchpoint is showing as a
hardware watchpoint, but afterwards it is showing as a software
watchpoint. Additionally, note that we clearly told the user we
created a hardware watchpoint:
(gdb) watch var
Hardware watchpoint 1: var
I think this is bad. I used `starti`, but if the user did `start` or
even `run` then the inferior is going to be _very_ slow, which will be
unexpected -- after all, we clearly told the user that we created a
hardware watchpoint, and the manual clearly says that hardware
watchpoints are fast (at least compared to s/w watchpoints).
In this patch I propose adding a new warning which will be emitted
when GDB downgrades a h/w watchpoint to s/w. The session now looks
like this:
(gdb) p sizeof var
$1 = 4000
(gdb) watch var
Hardware watchpoint 1: var
(gdb) info watchpoints
Num Type Disp Enb Address What
1 hw watchpoint keep y var
(gdb) starti
Starting program: /home/andrew/tmp/watch
warning: watchpoint 1 downgraded to software watchpoint
Program stopped.
0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) info watchpoints
Num Type Disp Enb Address What
1 watchpoint keep y var
(gdb)
The important line is:
warning: watchpoint 1 downgraded to software watchpoint
It's not much, but hopefully it will be enough to indicate to the user
that something unexpected has occurred, and hopefully, they will not
be surprised when the inferior runs much slower than they expected.
I've added an amd64 only test in gdb.arch/, I didn't want to try
adding this as a global test as other architectures might be able to
support the watchpoint request in h/w.
Also the test is skipped for extended-remote boards as there's a
different set of options for limiting hardware watchpoints on remote
targets, and this test isn't about them.
Reviewed-By: Lancelot Six <lancelot.six@amd.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I was seeing some failures in gdb.threads/omp-par-scope.exp when run
on a riscv64 target. It turns out the cause of the problem is that I
didn't have debug information installed for libgomp.so, which this
test makes use of. The test requires GDB to backtrace through a
libgomp function, and the riscv prologue unwinder was failing to
unwind this particular stack frame.
The reason for the failure to unwind was that the function prologue
includes a c.li (compressed load immediate) instruction, and the riscv
prologue scanning unwinder doesn't know what to do with this
instruction, though the unwinder does understand c.lui (compressed
load unsigned immediate).
This commit adds support for c.li. After this GDB is able to unwind
through libgomp, and I no longer see any unexpected failures in
gdb.threads/omp-par-scope.exp.
I've also included a new test in gdb.arch/ which specifically checks
for our c.li support.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gdb.arch/amd64-disp-step-self-call.exp
For test-case gdb.arch/amd64-disp-step-self-call.exp I get:
...
gdb compile failed, ld: warning: amd64-disp-step-self-call0.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
...
Fix this by adding the missing .note.GNU-stack.
Likewise for gdb.arch/i386-disp-step-self-call.exp.
Tested on x86_64-linux.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit:
commit cf141dd8ccd36efe833aae3ccdb060b517cc1112
Date: Wed Feb 22 12:15:34 2023 +0000
gdb: fix reg corruption from displaced stepping on amd64
Added two test scripts gdb.arch/amd64-disp-step-self-call.exp and
gdb.arch/i386-disp-step-self-call.exp. These scripts contained a test
that included a stack address in the test name, this makes it harder
to compare results between runs.
This commit gives the tests proper names that doesn't include an
address.
Also in gdb.arch/i386-disp-step-self-call.exp I noticed that we were
writing 8-bytes rather than 4 in order to clear the return address
entry on the stack. This is also fixed in this commit.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit aims to address a problem that exists with the current
approach to displaced stepping, and was identified in PR gdb/22921.
Displaced stepping is currently supported on AArch64, ARM, amd64,
i386, rs6000 (ppc), and s390. Of these, I believe there is a problem
with the current approach which will impact amd64 and ARM, and can
lead to random register corruption when the inferior makes use of
asynchronous signals and GDB is using displaced stepping.
The problem can be found in displaced_step_buffers::finish in
displaced-stepping.c, and is this; after GDB tries to perform a
displaced step, and the inferior stops, GDB classifies the stop into
one of two states, either the displaced step succeeded, or the
displaced step failed.
If the displaced step succeeded then gdbarch_displaced_step_fixup is
called, which has the job of fixing up the state of the current
inferior as if the step had not been performed in a displaced manner.
This all seems just fine.
However, if the displaced step is considered to have not completed
then GDB doesn't call gdbarch_displaced_step_fixup, instead GDB
remains in displaced_step_buffers::finish and just performs a minimal
fixup which involves adjusting the program counter back to its
original value.
The problem here is that for amd64 and ARM setting up for a displaced
step can involve changing the values in some temporary registers. If
the displaced step succeeds then this is fine; after the step the
temporary registers are restored to their original values in the
architecture specific code.
But if the displaced step does not succeed then the temporary
registers are never restored, and they retain their modified values.
In this context a temporary register is simply any register that is
not otherwise used by the instruction being stepped that the
architecture specific code considers safe to borrow for the lifetime
of the instruction being stepped.
In the bug PR gdb/22921, the amd64 instruction being stepped is
an rip-relative instruction like this:
jmp *0x2fe2(%rip)
When we displaced step this instruction we borrow a register, and
modify the instruction to something like:
jmp *0x2fe2(%rcx)
with %rcx having its value adjusted to contain the original %rip
value.
Now if the displaced step does not succeed, then %rcx will be left
with a corrupted value. Obviously corrupting any register is bad; in
the bug report this problem was spotted because %rcx is used as a
function argument register.
And finally, why might a displaced step not succeed? Asynchronous
signals provides one reason. GDB sets up for the displaced step and,
at that precise moment, the OS delivers a signal (SIGALRM in the bug
report), the signal stops the inferior at the address of the displaced
instruction. GDB cancels the displaced instruction, handles the
signal, and then tries again with the displaced step. But it is that
first cancellation of the displaced step that causes the problem; in
that case GDB (correctly) sees the displaced step as having not
completed, and so does not perform the architecture specific fixup,
leaving the register corrupted.
The reason why I think AArch64, rs600, i386, and s390 are not effected
by this problem is that I don't believe these architectures make use
of any temporary registers, so when a displaced step is not completed
successfully, the minimal fix up is sufficient.
On amd64 we use at most one temporary register.
On ARM, looking at arm_displaced_step_copy_insn_closure, we could
modify up to 16 temporary registers, and the instruction being
displaced stepped could be expanded to multiple replacement
instructions, which increases the chances of this bug triggering.
This commit only aims to address the issue on amd64 for now, though I
believe that the approach I'm proposing here might be applicable for
ARM too.
What I propose is that we always call gdbarch_displaced_step_fixup.
We will now pass an extra argument to gdbarch_displaced_step_fixup,
this a boolean that indicates whether GDB thinks the displaced step
completed successfully or not.
When this flag is false this indicates that the displaced step halted
for some "other" reason. On ARM GDB can potentially read the
inferior's program counter in order figure out how far through the
sequence of replacement instructions we got, and from that GDB can
figure out what fixup needs to be performed.
On targets like amd64 the problem is slightly easier as displaced
stepping only uses a single replacement instruction. If the displaced
step didn't complete the GDB knows that the single instruction didn't
execute.
The point is that by always calling gdbarch_displaced_step_fixup, each
architecture can now ensure that the inferior state is fixed up
correctly in all cases, not just the success case.
On amd64 this ensures that we always restore the temporary register
value, and so bug PR gdb/22921 is resolved.
In order to move all architectures to this new API, I have moved the
minimal roll-back version of the code inside the architecture specific
fixup functions for AArch64, rs600, s390, and ARM. For all of these
except ARM I think this is good enough, as no temporaries are used all
that's needed is the program counter restore anyway.
For ARM the minimal code is no worse than what we had before, though I
do consider this architecture's displaced-stepping broken.
I've updated the gdb.arch/amd64-disp-step.exp test to cover the
'jmpq*' instruction that was causing problems in the original bug, and
also added support for testing the displaced step in the presence of
asynchronous signal delivery.
I've also added two new tests (for amd64 and i386) that check that GDB
can correctly handle displaced stepping over a single instruction that
branches to itself. I added these tests after a first version of this
patch relied too much on checking the program-counter value in order
to see if the displaced instruction had executed. This works fine in
almost all cases, but when an instruction branches to itself a pure
program counter check is not sufficient. The new tests expose this
problem.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22921
Approved-By: Pedro Alves <pedro@palves.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GDB expected PC should point right after the SVC instruction when the
syscall is active. But some active syscalls keep PC pointing to the SVC
instruction itself.
This leads to a broken backtrace like:
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
#0 0xb6f8681c in pthread_cond_timedwait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0
#1 0xb6e21f80 in ?? ()
The reason is that .ARM.exidx unwinder gives up if PC does not point
right after the SVC (syscall) instruction. I did not investigate why but
some syscalls will point PC to the SVC instruction itself. This happens
for the "futex" syscall used by pthread_cond_timedwait.
That normally does not matter as ARM prologue unwinder gets called
instead of the .ARM.exidx one. Unfortunately some glibc calls have more
complicated prologue where the GDB unwinder fails to properly determine
the return address (that is in fact an orthogonal GDB bug). I expect it
is due to the "vpush" there in this case but I did not investigate it more:
Dump of assembler code for function pthread_cond_timedwait@@GLIBC_2.4:
0xb6f8757c <+0>: push {r4, r5, r6, r7, r8, r9, r10, r11, lr}
0xb6f87580 <+4>: mov r10, r2
0xb6f87584 <+8>: vpush {d8}
Regression tested on armv7l kernel 5.15.32-v7l+ (Raspbian 11).
Approved-By: Luis Machado <luis.machado@arm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With test-case gdb.arch/ftrace-insn-reloc.exp and host board
local-remote-host-notty and target board native-gdbserver I run into:
...
(gdb) info sharedlibrary^M
From To Syms Read Shared Object Library^M
$hex $hex Yes /lib64/ld-linux-x86-64.so.2^M
$hex $hex Yes /home/remote-host/libinproctrace.so^M
$hex $hex Yes /lib64/libm.so.6^M
$hex $hex Yes /lib64/libc.so.6^M
$hex $hex Yes /lib64/libdl.so.2^M
$hex $hex Yes (*) /usr/lib64/libstdc++.so.6^M
$hex $hex Yes (*) /lib64/libgcc_s.so.1^M
$hex $hex Yes /lib64/libpthread.so.0^M
(*): Shared library is missing debugging information.^M
(gdb) FAIL: gdb.arch/ftrace-insn-reloc.exp: IPA loaded
...
due to trying to match libinproctrace.so using the target path, while the
command lists it using the host path.
Fix this by making the regexp less strict.
Tested on x86_64-linux.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With test-case gdb.arch/ftrace-insn-reloc.exp and host board
local-remote-host-notty and target board native-gdbserver I run into:
...
(gdb) tstart^M
Target returns error code '.In-process agent library not loaded in process. \
Fast and static trace points unavailable.'.^M
(gdb) FAIL: gdb.arch/ftrace-insn-reloc.exp: start trace experiment
...
Fix this by:
- handling remote host in gdb_load_shlib, and
- moving the gdb_load_shlib to after the clean_restart, such that the
set solib-search-path can take effect.
Tested on x86_64-linux.
|
| |
|
|
|
|
| |
Fix test-case gdb.arch/i386-biarch-core.exp using gdb_download_remote host.
Tested on x86_64-linux.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With test-case gdb.arch/i386-sse.exp (and likewise gdb.arch/i386-avx.exp) and
host board local-remote-host-notty and target board native-gdbserver I run
into:
...
gdb compile failed, i386-sse.c:68:10: fatal error: \
../lib/precise-aligned-alloc.c: No such file or directory
#include "../lib/precise-aligned-alloc.c"
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...
Fix this using '#include "precise-aligned-alloc.c"' and making that work with
non-remote and remote host.
Tested on x86_64-linux.
|
| |
|
|
|
|
|
|
|
| |
In test-case gdb.arch/ftrace-insn-reloc.exp we generate two executables with
the same name, which is confusing and known to cause trouble.
Fix this by making the executable names unique.
Tested on x86_64-linux.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With test-case gdb.arch/amd64-stap-special-operands.exp and host board
local-remote-host-notty and target board native-gdbserver I run into:
...
(gdb) break -pstap three_arg^M
No probe matching objfile=`<any>', provider=`<any>', name=`three_arg'^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) FAIL: gdb.arch/amd64-stap-special-operands.exp: probe: three_arg: \
gdb_breakpoint: set breakpoint at -pstap three_arg
...
due to compiling two executables with the same name, and when uploading the
second one from host to build, we run into:
...
Upload from 127.0.0.1 failed, \
$outputs/gdb.arch/amd64-stap-special-operands/amd64-stap-special-operands: \
Text file busy.
...
Fix this by making the executable names unique.
Tested on x86_64-linux.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With test-case gdb.arch/i386-pkru.exp and target board native-gdbserver we run
into:
...
FAIL: gdb.arch/i386-pkru.exp: variable after reading pkru
...
This looks similar to the the problem for which there's already an xfail, so
fix this by extending the xfail matching.
Tested on x86_64-linux.
Also tested on openSUSE Tumbleweed, where all tests in the test-case pass.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's a number of gdb.arch/amd64*.exp test-cases that fail with host+target
board local-remote-host-native.exp because of using a .S file, generated from
a .c file.
If a test-case compiles the .S file when executing on remote host,
the .S file is already copied from build to host, such that it's available for
the compiler.
But that's not the case for the .c file, which is needed by gdb to show a
source line:
...
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, fn2 (y=y@entry=25, x=x@entry=6) at amd64-entry-value-inline.c:32^M
32 in gdb.arch/amd64-entry-value-inline.c^M
(gdb) FAIL: gdb.arch/amd64-entry-value-inline.exp: continue to breakpoint: \
break-here
...
Fix this by using "gdb_remote_download host <.c file>".
Tested on x86_64-linux, with host+target board local-remote-host-native.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test fails on Power 10 with the RHEL9 distro. It also fails on
Power 9.
The test set a the breakpoint in main that stops at line:
a = 9; /* start here */. The test then sets a break point at the same
line where it wants to start the test and does a continue. GDB does not
stop again on the same line where it is stopped, but rather continues to
the end of the program.
Initialize variable A to zero so the break on main will stop before setting
a break point on line a = 9; /* start here */.
Make the match on the breakpoint number generic.
Patch has been tested on Power 10 with RHEL 9, Power 10 with Ubuntu 22.04,
and Power 9 with Fedora 36 with no regression failures.
|
| |
|
|
|
|
|
| |
On AIX, the debugger cannot access vector registers before they
are first used by the inferior. Hence we change the test case
such that some vector registers are accessed by the variable 'x' in AIX
and other targets are not affected as a consequence of the same.
|
| |
|
|
|
|
|
|
|
| |
The orig_rax pseudo-register is Linux-specific and isn't relevant to
this test. The fs_base and gs_base registers are also not treated as
system registers in other OS ABIs. This allows the test to pass on
FreeBSD.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With test-cases gdb.arch/aarch64-mte-core.exp and gdb.arch/aarch64-pauth.exp I
run into compilation errors due to unsupported compilation flags.
Fix this by requiring the compilation flags, such that I have instead:
...
UNSUPPORTED: gdb.arch/aarch64-mte-core.exp: require failed: \
have_compile_flag -march=armv8.5-a+memtag
UNSUPPORTED: gdb.arch/aarch64-pauth.exp: require failed: \
have_compile_flag -mbranch-protection=pac-ret+leaf
...
Tested on aarch64-linux.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On SLE-11, with glibc 2.11.3, I run into:
...
(gdb) PASS: gdb.arch/amd64-disp-step-avx.exp: vex3: \
var128 has expected value after
continue^M
Continuing.^M
^M
Program received signal SIGSEGV, Segmentation fault.^M
0x0000000000400283 in _exit (status=0) at \
../sysdeps/unix/sysv/linux/_exit.c:33^M
33 ../sysdeps/unix/sysv/linux/_exit.c: No such file or directory.^M
(gdb) FAIL: gdb.arch/amd64-disp-step-avx.exp: \
continue until exit at amd64-disp-step-avx
...
This is not related to gdb, we get the same result by just running the exec.
The problem is that the test-case:
- calls glibc's _exit, and
- uses -nostartfiles -static, putting the burden for any necessary
initialization for calling glibc's _exit on the test-case itself.
So, when we get to the second insn in _exit:
...
000000000040acb0 <_exit>:
40acb0: 48 63 d7 movslq %edi,%rdx
40acb3: 64 4c 8b 14 25 00 00 mov %fs:0x0,%r10
...
no glibc-related initialization is done, and we run into the segfault.
Adding this (borrowed from __libc_start_main) in _start in the .S file is
sufficient to fix it:
...
.rept 200
nop
+ call __pthread_initialize_minimal
.endr
...
But that already doesn't compile with say glibc 2.31, and regardless I think
this sort of fix is too fragile.
We could of course fix this by simply not running to exit. But ideally we'd
have an exec that doesn't segfault when you just run it.
Alternatively, we could hand-code an _exit syscall and bypass glibc
all together. But I'd rather fix this in a way that simplifies the test-case.
Taking a step back, the -nostartfiles -static was added to address that the
xmm registers were not zero at main (which AFAICT is a valid thing to happen).
[ The change itself silently broke the test-case, needing further fixing by
commit 40310f30a51 ("gdb: make gdb.arch/amd64-disp-step-avx.exp actually test
displaced stepping"). ]
Instead, simplify things by reverting to the original situation:
- no -nostartfiles -static compilation flags,
- no _start in the .S file,
- use exit instead of _exit in the .S file,
and fix the original problem by setting the xmm registers to zero rather than
checking that they're zero.
Now that we're no longer forcing -static, add nopie to the flags to prevent
compilation failure with target board unix/-fPIE/-pie.
Tested on x86_64-linux.
PR testsuite/30132
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30132
|
| |
|
|
|
|
|
| |
Factor out new proc linux_kernel_version from test-case
gdb.arch/i386-pkru.exp.
Tested on x86_64-linux.
|
| |
|
|
|
|
|
| |
Change gdb.arch to use clean_restart more consistently.
|
| |
|
|
|
|
| |
Add new proc is_x86_64_m64_target and use it where appropriate.
Tested on x86_64-linux.
|
| |
|
|
|
|
|
|
| |
Pedro pointed out that only PPC can possibly have altivec, so we can
move the target check into allow_altivec_tests.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A number of tests will exit early without saying why. This patch adds
"unsupported" at spots like this that I could readily find.
There are definitely more of these; for example dw2-ranges.exp fails
silently because a compilation fails. I didn't attempt to address
these as that is a much larger task.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A few tests work on two different targets that can't be detected with
a single call to istarget -- that proc only accepts globs, not regular
expressions.
This patch introduces a new is_any_target proc and then converts these
tests to use it in a 'require'.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This changes many tests to use require when checking 'istarget'. A
few of these conversions were already done in earlier patches.
No change was needed to 'require' to make this work, due to the way it
is written. I think the result looks pretty clear, and it has the
bonus of helping to ensure that the reason that a test is skipped is
always logged.
|
| |
|
|
|
|
|
|
| |
This renames skip_vsx_tests to allow_vsx_tests and updates it users to
use require.
|
| |
|
|
|
|
|
|
| |
This renames skip_power_isa_3_1_tests to allow_power_isa_3_1_tests and
updates its users to use require.
|
| |
|
|
|
|
|
|
| |
This renames skip_float_test to allow_float_test and updates its users
to use require.
|
| |
|
|
|
|
|
|
| |
This renames skip_altivec_tests to allow_altivec_tests and updates its
users to use require.
|
| |
|
|
|
|
|
|
| |
This changes skip_python_tests to invert the sense, and renames it to
allow_python_tests.
|
| |
|
|
|
|
|
|
| |
This changes skip_avx512fp16_tests to invert the sense, and renames it
to allow_avx512fp16_tests.
|
| |
|
|
|
|
|
|
| |
This changes skip_avx512bf16_tests to invert the sense, and renames it
to allow_avx512bf16_tests.
|
| |
|
|
|
|
|
|
| |
This changes skip_aarch64_sve_tests to invert the sense, and renames
it to allow_aarch64_sve_tests.
|
| |
|
|
|
|
|
|
| |
This changes gdb_skip_xml_test to invert the sense, and renames it to
allow_xml_test.
|
| |
|
|
|
|
|
| |
This changes some tests to use "require gdb_skip_xml_test".
|
| |
|
|
|
|
|
| |
This changes some tests to use "require isnative".
|
| |
|
|
|
|
|
| |
This changes some tests to use "require is_amd64_regs_target".
|
| |
|
|
|
|
|
| |
This changes some tests to use "require is_aarch32_target".
|
| |
|
|
|
|
|
| |
This changes some tests to use "require is_aarch64_target".
|
| |
|
|
|
|
|
| |
This changes some tests to use "require support_displaced_stepping".
|
| |
|
|
|
|
|
| |
This changes some tests to use "require" with !skip_avx_*.
|
| |
|
|
|
|
|
| |
This changes some tests to use "require !skip_aarch64_sve_tests".
|
| |
|
|
|
|
|
| |
This changes some tests to use "require is_x86_like_target".
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On a x86_64-linux machine with pkru register, I run into:
...
(gdb) PASS: gdb.arch/i386-pkru.exp: set pkru value
info register pkru^M
pkru 0x12345678 305419896^M
(gdb) FAIL: gdb.arch/i386-pkru.exp: read value after setting value
...
This is a regression due to kernel commit e84ba47e313d ("x86/fpu: Hook up PKRU
onto ptrace()"). This is fixed by recent kernel commit 4a804c4f8356
("x86/fpu: Allow PKRU to be (once again) written by ptrace.").
The regression occurs for kernel versions v5.14-rc1 (the first tag containing
the regression) up to but excluding v6.2-rc1 (the first tag containing the fix).
Fix this by adding an xfail for the appropriate kernel versions.
Tested on x86_64-linux.
PR testsuite/29790
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29790
|
| |
|
|
|
|
|
| |
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PR gdb/28947
The address_significant gdbarch setting was introduced as a way to remove
non-address bits from pointers, and it is specified by a constant. This
constant represents the number of address bits in a pointer.
Right now AArch64 is the only architecture that uses it, and 56 was a
correct option so far.
But if we are using Pointer Authentication (PAuth), we might use up to 2 bytes
from the address space to store the required information. We could also have
cases where we're using both PAuth and MTE.
We could adjust the constant to 48 to cover those cases, but this doesn't
cover the case where GDB needs to sign-extend kernel addresses after removal
of the non-address bits.
This has worked so far because bit 55 is used to select between kernel-space
and user-space addresses. But trying to clear a range of bits crossing the
bit 55 boundary requires the hook to be smarter.
The following patch renames the gdbarch hook from significant_addr_bit to
remove_non_address_bits and passes a pointer as opposed to the number of
bits. The hook is now responsible for removing the required non-address bits
and sign-extending the address if needed.
While at it, make GDB and GDBServer share some more code for aarch64 and add a
new arch-specific testcase gdb.arch/aarch64-non-address-bits.exp.
Bug-url: https://sourceware.org/bugzilla/show_bug.cgi?id=28947
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
On s390x-linux, I run into:
...
DUPLICATE: gdb.arch/s390-multiarch.exp: Linux v2
DUPLICATE: gdb.arch/s390-multiarch.exp: Linux v2
DUPLICATE: gdb.arch/s390-multiarch.exp: Linux v2
...
Fix this by using with_test_prefix.
Tested on s390x-linux.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
--enable-targets=all
On s390x-linux, I run into:
...
DUPLICATE: gdb.arch/s390-disassembler-options.exp: \
show disassembler-options esa
...
First, reproduce this on x86_64-linux with --enable-targets=all, by replacing
the test for 'istarget "s390*-*-*"' with a test for 'get_set_option_choices
"set architecture" "s390"'.
Fix the DUPLICATE by using with_test_prefix.
Also modernize the test-case by using clean_restart instead of gdb_exit/gdb_start.
Tested on x86_64-linux.
|
