| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Since commit c4a3dbaf113 ("Expose current 'print' settings to Python") we
have:
...
(gdb) print /x $bnd0 = {0x10, 0x20}^M
$22 = {lbound = 0x10, ubound = 0x20} : size 0x11^M
(gdb) FAIL: gdb.arch/i386-mpx.exp: verify size for bnd0
...
The regexp in the test-case expects "size 17".
Fix this by updating the regexp.
Tested on x86_64-linux.
|
|
The -msign-return-address switch has been dropped from GCC, but some
older compiler may still support it. Make sure we try both
-msign-return-address and -mbranch-protection before bailing out when
running gdb.arch/aarch64-pauth.exp.
|
|
It is not necessary to call get_compiler_info before calling
test_compiler_info, and, after recent commits that removed setting up
the gcc_compiled, true, and false globals from get_compiler_info,
there is now no longer any need for any test script to call
get_compiler_info directly.
As a result every call to get_compiler_info outside of lib/gdb.exp is
redundant, and this commit removes them all.
There should be no change in what is tested after this commit.
|
|
The following commit changes the output format for the isel instruction on
PowerPC.
commit dd4832bf3efc1bd1797a6b9188260692b8b0db52 Introduces error in test
Author: Dmitry Selyutin <ghostmansd@gmail.com>
Date: Tue May 24 13:46:35 2022 +0000
opcodes: introduce BC field; fix isel
Per Power ISA Version 3.1B 3.3.12, isel uses BC field rather than CRB
field present in binutils sources. Also, per 1.6.2, BC has the same
semantics as BA and BB fields, so this should keep the same flags and
mask, only with the different offset.
opcodes/
* ppc-opc.c
(BC): Define new field, with the same definition as CRB field,
but with the PPC_OPERAND_CR_BIT flag present.
gas/
* testsuite/gas/ppc/476.d: Update.
* testsuite/gas/ppc/a2.d: Update.
* testsuite/gas/ppc/e500.d: Update.
* testsuite/gas/ppc/power7.d: Update.
<snip>
--- a/gas/testsuite/gas/ppc/476.d
+++ b/gas/testsuite/gas/ppc/476.d
@@ -209,7 +209,7 @@ Disassembly of section \.text:
.*: (7c 20 07 8c|8c 07 20 7c) ici 1
.*: (7c 03 27 cc|cc 27 03 7c) icread r3,r4
.*: (50 83 65 36|36 65 83 50) rlwimi r3,r4,12,20,27
-.*: (7c 43 27 1e|1e 27 43 7c) isel r2,r3,r4,28
+.*: (7c 43 27 1e|1e 27 43 7c) isel r2,r3,r4,4\*cr7\+lt
The above change breaks the gdb regression test gdb.arch/powerpc-power7.exp
on Power 7, Power 8, Power 9 and Power 10.
This patch updates the regression test gdb.arch/powerpc-power7.exp with
the new expected output for the isel instruction.
The patch has been tested on Power 7 and Power 10 to verify the patch fixes
the test.
|
|
The .quad statement stores the 64-bit hex value in Endian order. When used
to store a 64-bit prefix instructions on Big Endian (BE) systems, the .quad
statement stores the 32-bit suffix followed by the 32-bit prefix rather
than the expected order of prefix word followed by the suffix word. GDB
fetches 32-bits at a time when disassembling instructions. The disassembly
on BE gets messed up since GDB fetches the suffix first and interprets it
as a word instruction not a prefixed instruction. When gdb fetches the
prefix part of the instruction, following the initial suffix word, gdb
associates the prefix word incorrectly with the following 32-bits as the
suffix for the instruction when in fact it is the following instruction.
For example on BE we have two prefixed instructions stored using the
.quad statement as follows:
addr word GDB action
---------------------------------------------
1 suffix inst A <- GDB interprets as a word instruction
2 prefix inst A <- GDB uses this prefix with
3 suffix inst B <- this suffix rather than the suffix at addr 1.
4 prefix inst B
This patch changes the .quad statement into two .longs to explicitly store
the prefix followed by the suffix of the instruction.
The patch rearranges the instructions to put all of the word instructions
together followed by the prefix instructions for clarity.
The patch has been tested on Power 10 and Power 7 BE and LE to verify
the change works as expected.
|
|
This will allow the unwind info to explicitly specify a different value
for the return address from the link register.
Such usage, although uncommon, is valid and useful for signal frames.
It is also supported by aadwarf64 from ARM (Note 9 in [1]).
Ref https://sourceware.org/pipermail/gdb/2022-May/050091.html
[1] https://github.com/ARM-software/abi-aa/blob/2022Q1/aadwarf64/aadwarf64.rst#dwarf-register-names
Signed-off-by: Luis Machado <luis.machado@arm.com>
|
|
and gdb.arch/vsx-regs.exp
The format for printing the floating point values was changed by commit:
commit 56262a931b7ca8ee3ec9104bc7e9e0b40cf3d64e
Author: Tom Tromey <tromey@adacore.com>
Date: Thu Feb 17 13:43:59 2022 -0700
Change how "print/x" displays floating-point value
Currently, "print/x" will display a floating-point value by first
casting it to an integer type. This yields weird results like:
(gdb) print/x 1.5
$1 = 0x1
...
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16242
The above change results in 417 regression test failures since the expected
Power vector register output no longer match.
This patch updates the expected Altivec floating point register prints to
the hexadecimal format for both big endian and little endian systems. The
patch also fixes a formatting isue with the decimal_vector expected value
assign statements.
The expected VSX vector_register1, vector_register1_vr, vector_register2,
vector_register2_vr variables are updated to include the new float128 entry.
Additionally, the comment in the vsx expect file about the initialization
of the vs registers is updated.
The patch has been tested on Power 10, Power 8 LE and Power 8 BE.
|
|
LLVM's lld linker doesn't have the "-Ttext-segment" option, but
"--image-base" can be used instead.
To centralize the logic of checking which option is supported, add the
text_segment option to gdb_compile. Change tests that are currently
using -Ttext-segment to use that new option instead.
This patch fixes only compilation error, for example:
Before:
$ make check TESTS="gdb.base/jit-elf.exp" RUNTESTFLAGS="CC_FOR_TARGET=clang LDFLAGS_FOR_TARGET=-fuse-ld=ld"
Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jit-elf.exp ...
gdb compile failed, clang-13: warning: -Xlinker -Ttext-segment=0x7000000: 'linker' input unused [-Wunused-command-line-argument]
After:
$ make check TESTS="gdb.base/jit-elf.exp" RUNTESTFLAGS="CC_FOR_TARGET=clang LDFLAGS_FOR_TARGET=-fuse-ld=ld"
Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jit-elf.exp ...
FAIL: gdb.base/jit-elf.exp: one_jit_test-1: continue to breakpoint: break here 1
FAIL: gdb.base/jit-elf.exp: one_jit_test-1: continue to breakpoint: break here 2
FAIL: gdb.base/jit-elf.exp: one_jit_test-2: continue to breakpoint: break here 1
FAIL: gdb.base/jit-elf.exp: one_jit_test-2: info function ^jit_function
FAIL: gdb.base/jit-elf.exp: one_jit_test-2: continue to breakpoint: break here 2
FAIL: gdb.base/jit-elf.exp: attach: one_jit_test-2: continue to breakpoint: break here 1
FAIL: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach
FAIL: gdb.base/jit-elf.exp: PIE: one_jit_test-1: continue to breakpoint: break here 1
FAIL: gdb.base/jit-elf.exp: PIE: one_jit_test-1: continue to breakpoint: break here 2
=== gdb Summary ===
# of expected passes 26
# of unexpected failures 9
Change-Id: I3678c5c9bbfc2f80671698e28a038e6b3d14e635
|
|
call_site_find_chain_1 has a comment claiming that recursive calls
would be too expensive. However, I doubt this is so expensive; and
furthermore the explicit state management approach here is difficult
both to understand and to modify. This patch changes this code to use
explicit recursion, so that a subsequent patch can generalize this
code without undue trauma.
Additionally, I think this patch detects a latent bug in the recursion
code. (It's hard for me to be completely certain.) The bug is that
when a new target_call_site is entered, the code does:
if (target_call_site)
{
if (addr_hash.insert (target_call_site->pc ()).second)
{
/* Successfully entered TARGET_CALL_SITE. */
chain.push_back (target_call_site);
break;
}
}
Here, if entering the target_call_site fails, then any tail_call_next
elements in this call site are not visited. However, if this code
does happen to enter a call site, then the tail_call_next elements
will be visited during backtracking. This applies when doing the
backtracking as well -- it will only continue through a given chain as
long as each element in the chain can successfully be visited.
I'd appreciate some review of this. If this behavior is intentional,
it can be added to the new implementation.
|
|
This commit updates the copyright year range in the script
gdb/testsuite/gdb.arch/powerpc-power10.exp. The update was
performed by running gdb/copyright.py again, to make sure
that the copyright year range will be automatically updated
in years forward.
|
|
The copyright year and holder line is slight malformed, missing
a space after a comma, and this is sufficient for gdb's
copyright.py script to miss this file during its automated
copyright year update.
This commit fixes this.
|
|
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
|
|
Permanent program breakpoints (ones inserted into the code) other than
the one GDB uses for POWER (0x7fe00008) did not result in stop but
caused GDB to loop infinitely.
This was because GDB did not recognize trap instructions other than
"trap". For example, "tw 12, 4, 4" was not be recognized, causing GDB
to loop forever.
This commit fixes this by providing POWER specific hook
(gdbarch_program_breakpoint_here_p) recognizing all tw, twi, td and tdi
instructions.
Tested on Linux on PowerPC e500 and on QEMU PPC64le.
|
|
Test-cases gdb.arch/i386-{avx,sse}.exp use assembly instructions that require
the memory operands to be aligned to a certain boundary, and the test-cases
use C11's _Alignas to make that happen.
The draw-back of using _Alignas is that while it does enforce a minimum
alignment, the actual alignment may be bigger, which makes the following
scenario possible:
- copy say, gdb.arch/i386-avx.c as basis for a new test-case
- run the test-case and observe a PASS
- commit the new test-case in the supposition that the test-case is correct
and well-tested
- run later into a failure on a different test setup (which may be a setup
where reproduction and investigation is more difficult and time-consuming),
and find out that the specified alignment was incorrect and should have been
updated to say, 64 bytes. The initial PASS occurred only because the actual
alignment happened to be greater than required.
The idea of having precise alignment as a means of having more predictable
execution which allows flushing out bugs earlier, has been filed as PR
gcc/103095.
Add a new file lib/precise-aligned-alloc.c with functions
precise_aligned_alloc and precise_aligned_dup, to support precise alignment.
Use precise_aligned_dup in aforementioned test-cases to:
- verify that the specified alignment is indeed sufficient, rather
than too little but accidentally over-aligned.
- prevent the same type of problems in any new test-cases based on these
Tested on x86_64-linux, with both gcc and clang.
|
|
When running test-case gdb.arch/i386-avx.exp with clang I ran into:
...
(gdb) PASS: gdb.arch/i386-avx.exp: set first breakpoint in main
continue^M
Continuing.^M
^M
Program received signal SIGSEGV, Segmentation fault.^M
0x000000000040052b in main (argc=1, argv=0x7fffffffd3c8) at i386-avx.c:54^M
54 asm ("vmovaps 0(%0), %%ymm0\n\t"^M
(gdb) FAIL: gdb.arch/i386-avx.exp: continue to breakpoint: \
continue to first breakpoint in main
...
The problem is that the vmovaps insn requires an 256-bit (or 32-byte) aligned
address, and it's only 16-byte aligned:
...
(gdb) p /x $rax
$1 = 0x601030
...
Fix this by using a sufficiently aligned address, using _Alignas.
Compile using -std=gnu11 to support _Alignas.
Likewise in gdb.arch/i386-sse.exp.
Tested on x86_64-linux, with both gcc and clang.
|
|
When running test-case gdb.arch/i386-pkru.exp on a machine with "Memory
Protection Keys for Userspace" support, we run into:
...
(gdb) PASS: gdb.arch/i386-pkru.exp: probe PKRU support
print $pkru^M
$2 = 1431655764^M
(gdb) FAIL: gdb.arch/i386-pkru.exp: pkru register
...
The test-case expects the $pkru register to have the default value 0, matching
the "init state" of 0 defined by the XSAVE hardware.
Since linux kernel version v4.9 containing commit acd547b29880 ("x86/pkeys:
Default to a restrictive init PKRU"), the register is set to 0x55555554 by
default (which matches the printed decimal value above).
Fix the FAIL by accepting this value for linux.
Tested on x86_64-linux.
|
|
The test complains of duplicate tests.
DUPLICATE: gdb.arch/ppc-longdouble.exp: continue to breakpoint: return
The do_test calls gdb_continue_to_breakpoint "return". The duplicates
are the result of calling do_test three times with different arguments.
This patch fixes the duplicate tests by adding $name to the
gdb_continue_to_breakpoint argument.
Patch tested on Power 10 ppc64le GNU/Linux, no duplicate tests reported,
no new regression errors.
|
|
Add a regression test-case for commit a50bdb99afe "[gdb/tdep, rs6000] Don't
skip system call in skip_prologue":
- set a breakpoint on a local copy of glibc's _exit, and
- verify that it triggers.
The test-case uses an assembly file by default, but also has the possibility
to use a C source file instead.
Tested on ppc64le-linux. Verified that the test-case fails without
aforementioned commit, and passes with the commit. Both with assembly
and C source.
|
|
On powerpc64le-linux, with test-case gdb.arch/powerpc-addpcis.exp I run into
SIGILL:
...
(gdb) PASS: gdb.arch/powerpc-addpcis.exp: get hexadecimal valueof "$r3"
stepi^M
^M
Program terminated with signal SIGILL, Illegal instruction.^M
The program no longer exists.^M
(gdb) PASS: gdb.arch/powerpc-addpcis.exp: set r4
...
because it's a power9 insn, and I'm running on a power8 machine.
Fix this by handling the SIGILL. Likewise in gdb.arch/powerpc-lnia.exp.
Tested on powerpc64le-linux.
|
|
I noticed some files in the test-suite have GPLv2 notices.
Update these to GPLv3.
|
|
When running test-case gdb.arch/i386-mpx.exp with target board
native-gdbserver, I run into:
...
(gdb) PASS: gdb.arch/i386-mpx.exp: verify size for bnd0
Remote debugging from host ::1, port 42328^M
quit^M
A debugging session is active.^M
^M
Inferior 1 [process 19679] will be killed.^M
^M
Quit anyway? (y or n) monitor exit^M
Please answer y or n.^M
A debugging session is active.^M
^M
Inferior 1 [process 19679] will be killed.^M
^M
Quit anyway? (y or n) WARNING: Timed out waiting for EOF in server after monitor exit
...
The problem is that the test-case sends a quit at the end (without verifying
the result of this in any way):
...
send_gdb "quit\n"
...
Fix this by removing the quit.
Tested on x86_64-linux.
|
|
When running test-case gdb.dwarf2/dw2-restrict.exp on openSUSE Leap 15.2 with
gcc-PIE installed (switching compiler default to -fPIE/-pie), I get:
...
gdb compile failed, ld: outputs/gdb.dwarf2/dw2-restrict/dw2-restrict0.o: \
warning: relocation in read-only section `.text'
ld: warning: creating DT_TEXTREL in a PIE
UNTESTED: gdb.dwarf2/dw2-restrict.exp: failed to prepare
...
This is due to using a hardcoded .S file that was generated with -fno-PIE.
Fix this by adding the missing nopie.
Likewise in gdb.arch/amd64-tailcall-noret.exp.
Tested on x86_64-linux.
|
|
While working on other problems, I encountered situations where GDB
fails to properly unwind the stack because some functions use the C.MV
instruction in the prologue. The prologue scanner stops when it hits
this instruction assuming its job is done at this point. Unfortunately
the prologue is not necessarily finished yet, preventing GDB to properly
unwind.
This commit adds support for handling such instruction in
riscv_scan_prologue.
Note that C.MV is part of the compressed instruction set. The MV
counterpart from the base ISA is a pseudo instruction that expands to
'ADDI RD,RS1,0' which is already supported.
Tested on riscv64-linux-gnu.
All feedback are welcome.
|
|
As follow-up to this discussion:
https://sourceware.org/pipermail/gdb-patches/2020-August/171385.html
... make runto_main not pass no-message to runto. This means that if we
fail to run to main, for some reason, we'll emit a FAIL. This is the
behavior we want the majority of (if not all) the time.
Without this, we rely on tests logging a failure if runto_main fails,
otherwise. They do so in a very inconsisteny mannet, sometimes using
"fail", "unsupported" or "untested". The messages also vary widly.
This patch removes all these messages as well.
Also, remove a few "fail" where we call runto (and not runto_main). by
default (without an explicit no-message argument), runto prints a
failure already. In two places, gdb.multi/multi-re-run.exp and
gdb.python/py-pp-registration.exp, remove "message" passed to runto.
This removes a few PASSes that we don't care about (but FAILs will still
be printed if we fail to run to where we want to). This aligns their
behavior with the rest of the testsuite.
Change-Id: Ib763c98c5f4fb6898886b635210d7c34bd4b9023
|
|
Minimize gdb restarts, applying the following rules:
- don't use prepare_for_testing unless necessary
- don't use clean_restart unless necessary
Also, if possible, replace build_for_executable + clean_restart
with prepare_for_testing for brevity.
Touches 68 test-cases.
Tested on x86_64-linux.
|
|
A previous commit added the
gdb.arch/riscv64-unwind-prologue-with-ld-lw.exp testcase, but one of its
associated file was named after a previous version of the test.
This commit fixes this and makes sure that all the files linked to this
testcase share the same prefix in the name.
Tested on riscv64 GNU/Linux.
|
|
On a machine on Open Build Service I'm running into a SIGILL for test-case
gdb.arch/amd64-disp-step-avx.exp:
...
Program received signal SIGILL, Illegal instruction.^M
test_rip_vex2 () at gdb.arch/amd64-disp-step-avx.S:40^M
40 vmovsd ro_var(%rip),%xmm0^M
(gdb) FAIL: gdb.arch/amd64-disp-step-avx.exp: vex2: \
continue to test_rip_vex2_end
...
The SIGILL happens when trying to execute the first avx instruction in the
executable.
I can't directly access the machine, but looking at the log for test-case
gdb.arch/i386-avx.exp, it seems that there's no avx support:
...
Breakpoint 1, main (argc=1, argv=0x7fffffffd6b8) at gdb.arch/i386-avx.c:68^M
68 if (have_avx ())^M
(gdb) print have_avx ()^M
$1 = 0^M
...
Fix this by:
- adding a gdb_caching_proc have_avx, similar to have_mpx, using the have_avx
function from gdb.arch/i386-avx.c
- using proc have_avx in both gdb/testsuite/gdb.arch/amd64-disp-step-avx.exp
and gdb/testsuite/gdb.arch/i386-avx.exp.
Tested on my x86_64-linux laptop with avx support, where both test-cases pass.
gdb/testsuite/ChangeLog:
2021-09-04 Tom de Vries <tdevries@suse.de>
PR testsuite/26950
* gdb/testsuite/gdb.arch/i386-avx.c (main): Remove call to have_avx.
(have_avx): Move ...
* gdb/testsuite/lib/gdb.exp (have_avx): ... here. New proc.
* gdb/testsuite/gdb.arch/amd64-disp-step-avx.exp: Use have_avx.
* gdb/testsuite/gdb.arch/i386-avx.exp: Same.
|
|
Values of type _Float16 and _Float16 _Complex can now be used on CPUs with
AVX512-FP16 support. Return values of those types are located in XMM0.
Compiler support for gcc and clang is in progress, see e.g.:
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574117.html
gdb/ChangeLog:
2021-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com>
* amd64-tdep.c (amd64_classify): Classify _Float16 and
_Float16 _Complex as AMD64_SSE.
* i386-tdep.c (i386_extract_return_value): Read _Float16 and
_Float16 _Complex from xmm0.
gdb/testsuite/ChangeLog:
2021-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com>
* gdb.arch/x86-avx512fp16-abi.c: New file.
* gdb.arch/x86-avx512fp16-abi.exp: New file.
|
|
This adds support for the half datatype, FP16, to the AVX512 register printing.
gdb/ChangeLog:
2020-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com>
* i386-tdep.c (i386_zmm_type) <v32_half>: New field.
(i386_ymm_type) <v16_half>: New field.
(i386_gdbarch_init): Add set_gdbarch_half_format.
* features/i386/64bit-avx512.xml: Add half type.
* features/i386/64bit-avx512.c: Regenerated.
* features/i386/64bit-sse.xml: Add half type.
* features/i386/64bit-sse.c: Regenerated.
gdb/testsuite/ChangeLog:
2021-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com>
* gdb.arch/x86-avx512fp16.c: New file.
* gdb.arch/x86-avx512fp16.exp: New file.
* lib/gdb.exp (skip_avx512fp16_tests): New function.
|
|
Values of type bfloat16 can also be used on 32-bit targets, which was missed
in the original enablement. This also adjusts the testcase to pass with
"unix/-m32", where only the lower 8 AVX registers are available.
gdb/ChangeLog:
2021-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com>
* features/i386/32bit-sse.xml: Add bfloat16 type.
* features/i386/32bit-sse.c: Regenerated.
gdb/testsuite/ChangeLog:
2021-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com>
* gdb.arch/x86-avx512bf16.exp: Only use x/z/ymm 0-7.
|
|
While working on the testsuite, I ended up noticing that GDB fails to
produce a full backtrace from a thread waiting in pthread_join. When
selecting the waiting thread and using the 'bt' command, the following
result can be observed:
(gdb) bt
#0 0x0000003ff7fccd20 in __futex_abstimed_wait_common64 () from /lib/riscv64-linux-gnu/libpthread.so.0
#1 0x0000003ff7fc43da in __pthread_clockjoin_ex () from /lib/riscv64-linux-gnu/libpthread.so.0
Backtrace stopped: frame did not save the PC
On my platform, I do not have debug symbols for glibc, so I need to rely
on prologue analysis in order to unwind stack.
Here is what the function prologue looks like:
(gdb) disassemble __pthread_clockjoin_ex
Dump of assembler code for function __pthread_clockjoin_ex:
0x0000003ff7fc42de <+0>: addi sp,sp,-144
0x0000003ff7fc42e0 <+2>: sd s5,88(sp)
0x0000003ff7fc42e2 <+4>: auipc s5,0xd
0x0000003ff7fc42e6 <+8>: ld s5,-2(s5) # 0x3ff7fd12e0
0x0000003ff7fc42ea <+12>: ld a5,0(s5)
0x0000003ff7fc42ee <+16>: sd ra,136(sp)
0x0000003ff7fc42f0 <+18>: sd s0,128(sp)
0x0000003ff7fc42f2 <+20>: sd s1,120(sp)
0x0000003ff7fc42f4 <+22>: sd s2,112(sp)
0x0000003ff7fc42f6 <+24>: sd s3,104(sp)
0x0000003ff7fc42f8 <+26>: sd s4,96(sp)
0x0000003ff7fc42fa <+28>: sd s6,80(sp)
0x0000003ff7fc42fc <+30>: sd s7,72(sp)
0x0000003ff7fc42fe <+32>: sd s8,64(sp)
0x0000003ff7fc4300 <+34>: sd s9,56(sp)
0x0000003ff7fc4302 <+36>: sd a5,40(sp)
As far as prologue analysis is concerned, the most interesting part is
done at address 0x0000003ff7fc42ee (<+16>): 'sd ra,136(sp)'. This stores
the RA (return address) register on the stack, which is the information
we are looking for in order to identify the caller.
In the current implementation of the prologue scanner, GDB stops when
hitting 0x0000003ff7fc42e6 (<+8>) because it does not know what to do
with the 'ld' instruction. GDB thinks it reached the end of the
prologue but have not yet reached the important part, which explain
GDB's inability to unwind past this point.
The section of the prologue starting at <+4> until <+12> is used to load
the stack canary[1], which will then be placed on the stack at <+36> at
the end of the prologue.
In order to have the prologue properly handled, this commit proposes to
add support for the ld instruction in the RISC-V prologue scanner.
I guess riscv32 would use lw in such situation so this patch also adds
support for this instruction.
With this patch applied, gdb is now able to unwind past pthread_join:
(gdb) bt
#0 0x0000003ff7fccd20 in __futex_abstimed_wait_common64 () from /lib/riscv64-linux-gnu/libpthread.so.0
#1 0x0000003ff7fc43da in __pthread_clockjoin_ex () from /lib/riscv64-linux-gnu/libpthread.so.0
#2 0x0000002aaaaaa88e in bar() ()
#3 0x0000002aaaaaa8c4 in foo() ()
#4 0x0000002aaaaaa8da in main ()
I have had a look to see if I could reproduce this easily, but in my
simple testcases using '-fstack-protector-all', the canary is loaded
after the RA register is saved. I do not have a reliable way of
generating a prologue similar to the problematic one so I forged one
instead.
The testsuite have been run on riscv64 ubuntu 21.01 with no regression
observed.
[1] https://en.wikipedia.org/wiki/Buffer_overflow_protection#Canaries
|
|
This patch adds a file with the ISA 3.1 check. The ISA 3.1 check is
added to the test to ensure the test is only run on ISA 3.1 or newer.
gdb/testsuite/ChangeLog
2021-06-25 Carl Love <cel@us.ibm.com>
* gdb.arch/powerpc-plxv-norel.exp: Add call to skip_power_isa_3_1_tests.
* lib/gdb.exp(skip_power_isa_3_1_tests): New gdb_caching_proc test.
|
|
This patch updates the gdb test to use the new bgetar and bnstarl mnemonics
introduced in commit 5a4037661bccd156d65093f1f0cf2cd43f31e9d9. The test
previously used the bctar and bctarl mnemonics.
gdb/testsuite/ChangeLog
2021-06-17 Carl Love <cel@us.ibm.com>
* gdb.arch/powerpc-power8.exp(bctar, bctarl): Update mnemonics
to bgetar and bgetarl.
* gdb.arch/powerpc-power8.s((bctar, bctarl): Update comments
for mnemonics to bgetar and bnstarl.
|
|
gdb/ChangeLog
2021-06-15 Carl Love <cel@us.ibm.com>
* testsuite/gdb.arch/vsx-regs.exp (gdb_test_no_output): Fix typo
in set \$vs$i.v2_double.
|
|
Implement ARC target support for passing options to the disassembler
through the command interface. e.g.:
gdb> set disassembler-options cpu=hs38_linux ...
gdb/ChangeLog:
* NEWS: Document 'set disassembler-options' support for the ARC
target.
* arc-tdep.c (arc_gdbarch_init): Set
'gdbarch_valid_disassembler_options'.
gdb/doc/ChangeLog:
* gdb.texinfo (Source and Machine Code): Document 'set
disassembler-options' support for the ARC target.
gdb/testsuite/ChangeLog:
* gdb.arch/arc-disassembler-options.exp: New test.
* gdb.arch/arc-disassembler-options.s: New test source.
|
|
Add a powerpc64-prologue testcase, this is based on the existing
powerpc-prologue test, but updated for the powerpc64 (le) target.
YYYY-MM-DD Will Schmidt <will_schmidt@vnet.ibm.com>
gcc/testsuite/ChangeLog
* gdb.arch/powerpc64-prologue.c: New test to exercise prologues
for the powerpc64 LE target.
* gdb.arch/powerpc-prologue.exp: Test Harness.
|
|
This test has a little oversight: the test procedure doesn't actually
use its parameters, the commands and expected patterns are hard-coded,
so we always test with i386:x86-64, instead of with the three arches.
Fix that.
gdb/testsuite/ChangeLog:
* gdb.arch/amd64-osabi.exp (test_osabi_none): Use the
parameters.
Change-Id: Iee2c32963d09e502ae791d5df2b6c04a1f49a57a
|
|
The test checks for a particular ARCH level, but it needs to check for
ARCH levels from a minimum and upwards.
gdb/testsuite/ChangeLog:
2021-04-26 Luis Machado <luis.machado@linaro.org>
* gdb.arch/aarch64-dbreg-contents.c (set_watchpoint): Fix arch level
comparison.
|
|
Hi,
This test exercise updates to the F* and VS* registers
and verifies updates to the same. Note that the registers
overlap; the doubleword[1] portion of any VS0-VS31
register contains the F0-F31 register contents, so any updates
to one can be measured in the other.
Per a brief investigation, we see that dl_main() currently
uses some VSX instructions, so the VS* values are not
going to be zero when this testcase reaches main, where these
tests begin. The test harness does not explicitly
initialize the full VS* values, so the first test loop
that updates the F* values means our VS* values are
uninitalized and will fail the first set of checks.
This update explicitly initializes the doubleword[0] portion
of the VS* registers, to allow this test to succeed.
2021-04-12 Will Schmidt <will_schmidt@vnet.ibm.com>
gdb/testsuite/ChangeLog:
* gdb.arch/vsx-regs.exp: Initialize vs* doublewords.
|
|
Hi,
This is based on a patch originally written by Alan Modra.
Powerpc / Power10 ISA 3.1 adds prefixed instructions, which
are 8 bytes in length. This is in contrast to powerpc previously
always having 4 byte instruction length. This patch implements
changes to allow GDB to better detect prefixed instructions, and
handle single stepping across the 8 byte instructions.
Added #defines to help test for PNOP and prefix instructions.
Update ppc_displaced_step_copy_insn() to handle pnop and prefixed
instructions whem R=0 (non-pc-relative).
Updated ppc_displaced_step_fixup() to properly handle the offset
value matching the current instruction size
Updated the for-loop within ppc_deal_with_atomic_sequence() to
count instructions properly in case we have a mix of 4-byte and
8-byte instructions within the atomic_sequence_length.
Added testcase and harness to exercise pc-relative load/store
instructions with R=0.
2021-04-12 Will Schmidt <will_schmidt@vnet.ibm.com>
gdb/ChangeLog:
* rs6000-tdep.c: Add support for single-stepping of
prefixed instructions.
gdb/testsuite/ChangeLog:
* gdb.arch/powerpc-plxv-nonrel.s: Testcase using
non-relative plxv instructions.
* gdb.arch/powerpc-plxv-nonrel.exp: Testcase harness.
|
|
This addresses PR gdb/27525. The lnia and other variations
of the addpcis instruction write the value of the NIA into a target register.
If we are single-stepping across a breakpoint, the instruction is executed
from a displaced location, and thusly the written value of the PC/NIA
will be incorrect. The changes here will measure the displacement
offset, and adjust the target register value to compensate.
YYYY-MM-DD Will Schmidt <will_schmidt@vnet.ibm.com>
gdb/ChangeLog:
* rs6000-tdep.c (ppc_displaced_step_fixup): Update to handle
the addpcis/lnia instruction.
gdb/testsuite/ChangeLog:
* gdb.arch/powerpc-addpcis.exp: Testcase harness to
exercise single-stepping over subpcis,lnia,addpcis instructions
with displacement.
* gdb.arch/powerpc-addpcis.s: Testcase with stream
of addpcis/lnia/subpcis instructions.
* gdb.arch/powerpc-lnia.exp: Testcase harness to exercise
single-stepping over lnia instructions with displacement.
* gdb.arch/powerpc-lnia.s: Testcase with stream of
lnia instructions.
|
|
Inspired by the existing powerpc-power9.exp test, this is a
new test to cover the power10 instruction disassembly.
gdb/testsuite/ChangeLog:
2021-04-12 Will Schmidt <will_schmidt@vnet.ibm.com>
* gdb.arch/powerpc-power10.s: New test for instructions.
* gdb.arch/powerpc-power10.exp: Harness to run the test.
|
|
This patch adds a floating point 128-bit composite field to the vsx
register type. When printing the register with p/f the float128 field will
be printed as a 128-bit floating point value. A test case to verify the new
vsx register field is visible and correctly prints out the value of a 128-bit
floating point value is also added.
gdb/ChangeLog:
* rs6000-tdep.c (rs6000_builtin_type_vec128): Add t_float128 variable.
(rs6000_builtin_type_vec128): Add append_composite_type_field for
float128.
gdb/testsuite/ChangeLog:
* gdb.arch/vsx-vsr-float128.c: New test file.
* gdb.arch/vsx-vsr-float128.exp: New expect file.
|
|
Resolve some duplicate test name warnings in gdb.arch/powerpc-*.exp
tests by either extending the existing test names, or providing a new
test name.
gdb/testsuite/ChangeLog:
* gdb.arch/powerpc-disassembler-options.exp: Extend some test
names for uniqueness.
* gdb.arch/powerpc-fpscr-gcore.exp: Add more test names for
uniqueness.
|
|
Add an AArch64-specific test and a more generic memory tagging test that
other architectures can run.
Even though architectures not supporting memory tagging can run the memory
tagging tests, the runtime check will make the tests bail out early, as it
would make no sense to proceed without proper support.
It is also tricky to do any further runtime tests for memory tagging, given
we'd need to deal with tags, and those are arch-specific. Therefore the
test in gdb.base is more of a smoke test.
If an architecture wants to implement memory tagging, then it makes sense to
have tests within gdb.arch instead.
gdb/testsuite/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* gdb.arch/aarch64-mte.c: New file.
* gdb.arch/aarch64-mte.exp: New test.
* gdb.base/memtag.c: New file.
* gdb.base/memtag.exp: New test.
* lib/gdb.exp (supports_memtag): New function.
|
|
GDB for RISC-V always uses target descriptions. When the target
doesn't provide a target description then a default is selected.
Usually this default is selected based on the properties of the
executable being debugged. However, when there is no executable being
debugged we currently fallback to the riscv:rv64 target description as
the default. This leads to strange behaviour like this:
$ gdb
(gdb) set architecture riscv:rv32
(gdb) p sizeof ($pc)
$1 = 8
Despite the users specifically setting the architecture to riscv:rv32
GDB still thinks that the target has riscv:rv64 register sizes.
The above is a bit of a contrived situation. I actually ran into this
situation while trying to connect to a running riscv:rv32 target
without supplying an executable (the target didn't provide a target
description). When I tried to set a register on the target I ran into
errors because GDB was passing 8 bytes to the target rather than the
expected 4. Even when I manually specified the architecture (as
above) I couldn't convince GDB to only send 4 bytes.
This patch fixes this issue. Now, when we selected a default target
description we will make use of the user selected architecture to
guide our choice. In the above example we now get:
$ gdb
(gdb) set architecture riscv:rv32
(gdb) p sizeof ($pc)
$1 = 4
And my real world example of connecting to a remote without an
executable works fine.
I've used the fact that we can ask GDB about $pc even when no
executable is loaded as the basis for a test to cover this situation.
gdb/ChangeLog:
* riscv-tdep.c (riscv_features_from_gdbarch_info): Rename to...
(riscv_features_from_bfd): ...this. Change parameter type to
'bfd*', and update as required.
(riscv_find_default_target_description): Update call to
riscv_features_from_bfd. Select a default xlen based on
info.bfd_arch_info.
(riscv_gdbarch_init): Update call to riscv_features_from_bfd.
gdb/testsuite/ChangeLog:
* gdb.arch/riscv-default-tdesc.exp: New file.
|
|
Restrict the test gdb.arch/i386-biarch-core.exp to only run on
suitable targets.
gdb/testsuite/ChangeLog:
* gdb.arch/i386-biarch-core.exp: Add target check.
|
|
When running test-case gdb.arch/i386-gnu-cfi.exp with target board unix/-m32, I get:
...
(gdb) up 3^M
79 abort.c: No such file or directory.^M
(gdb) FAIL: gdb.arch/i386-gnu-cfi.exp: shift up to the modified frame
...
The preceding backtrace looks like this:
...
(gdb) bt^M
#0 0xf7fcf549 in __kernel_vsyscall ()^M
#1 0xf7ce8896 in __libc_signal_restore_set (set=0xffffc3bc) at \
../sysdeps/unix/sysv/linux/internal-signals.h:104^M
#2 __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:47^M
#3 0xf7cd0314 in __GI_abort () at abort.c:79^M
#4 0x0804919f in gate (gate=0x8049040 <abort@plt>, data=0x0) at gate.c:3^M
#5 0x08049176 in main () at i386-gnu-cfi.c:27^M
...
with function gate at position #4, while on another system where the test passes,
I see instead function gate at position #3.
Fix this by capturing the position of function gate in the backtrace, and
using that in the rest of the test instead of hardcoded constant 3.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-01-28 Tom de Vries <tdevries@suse.de>
* gdb.arch/i386-gnu-cfi.exp: Capture the position of function gate
in the backtrace, and use that in the rest of the test instead of
hardcoded constant 3. Use "frame" instead of "up" for robustness.
|
|
When running test-case gdb.arch/i386-sse-stack-align.exp on target board
unix/-m32, I run into:
...
(gdb) print (int) g0 ()^M
Invalid data type for function to be called.^M
(gdb) FAIL: gdb.arch/i386-sse-stack-align.exp: print (int) g0 ()
...
Gdb is supposed to use minimal symbol g0:
...
$ nm i386-sse-stack-align | grep g0
08049194 t g0
...
but instead it finds a g0 symbol in the debug info of libm, specifically in
./sysdeps/ieee754/ldbl-96/e_lgammal_r.c.
Fix this by renaming g[0-4] to test_g[0-4].
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-01-28 Tom de Vries <tdevries@suse.de>
* gdb.arch/i386-sse-stack-align.S: Rename g[0-4] to test_g[0-4].
* gdb.arch/i386-sse-stack-align.c: Same.
* gdb.arch/i386-sse-stack-align.exp: Same.
|
|
Enable displaced stepping over a BR/BLR instruction
Displaced stepping over an instruction executes a instruction in a
scratch area and then manually fixes up the PC address to leave
execution where it would have been if the instruction were in its
original location.
The BR instruction does not need modification in order to run correctly
at a different address, but the displaced step fixup method should not
manually adjust the PC since the BR instruction sets that value already.
The BLR instruction should also avoid such a fixup, but must also have
the link register modified to point to just after the original code
location rather than back to the scratch location.
This patch adds the above functionality.
We add this functionality by modifying aarch64_displaced_step_others
rather than by adding a new visitor method to aarch64_insn_visitor.
We choose this since it seems that visitor approach is designed
specifically for PC relative instructions (which must always be modified
when executed in a different location).
It seems that the BR and BLR instructions are more like the RET
instruction which is already handled specially in
aarch64_displaced_step_others.
This also means the gdbserver code to relocate an instruction when
creating a fast tracepoint does not need to be modified, since nothing
special is needed for the BR and BLR instructions there.
Regression tests showed nothing untoward on native aarch64 (though it
took a while for me to get the testcase to account for PIE).
------#####
Original observed (mis)behaviour before was that displaced stepping over
a BR or BLR instruction would not execute the function they called.
Most easily seen by putting a breakpoint with a condition on such an
instruction and a print statement in the functions they called.
When run with the breakpoint enabled the function is not called and
"numargs called" is not printed.
When run with the breakpoint disabled the function is called and the
message is printed.
--- GDB Session
~ [15:57:14] % gdb ../using-blr
Reading symbols from ../using-blr...done.
(gdb) disassemble blr_call_value
Dump of assembler code for function blr_call_value:
...
0x0000000000400560 <+28>: blr x2
...
0x00000000004005b8 <+116>: ret
End of assembler dump.
(gdb) break *0x0000000000400560
Breakpoint 1 at 0x400560: file ../using-blr.c, line 22.
(gdb) condition 1 10 == 0
(gdb) run
Starting program: /home/matmal01/using-blr
[Inferior 1 (process 33279) exited with code 012]
(gdb) disable 1
(gdb) run
Starting program: /home/matmal01/using-blr
numargs called
[Inferior 1 (process 33289) exited with code 012]
(gdb)
Test program:
---- using-blr ----
\#include <stdio.h>
typedef int (foo) (int, int);
typedef void (bar) (int, int);
struct sls_testclass {
foo *x;
bar *y;
int left;
int right;
};
__attribute__ ((noinline))
int blr_call_value (struct sls_testclass x)
{
int retval = x.x(x.left, x.right);
if (retval % 10)
return 100;
return 9;
}
__attribute__ ((noinline))
int blr_call (struct sls_testclass x)
{
x.y(x.left, x.right);
if (x.left % 10)
return 100;
return 9;
}
int
numargs (__attribute__ ((unused)) int left, __attribute__ ((unused)) int right)
{
printf("numargs called\n");
return 10;
}
void
altfunc (__attribute__ ((unused)) int left, __attribute__ ((unused)) int right)
{
printf("altfunc called\n");
}
int main(int argc, char **argv)
{
struct sls_testclass x = { .x = numargs, .y = altfunc, .left = 1, .right = 2 };
if (argc > 2)
{
blr_call (x);
}
else
blr_call_value (x);
return 10;
}
|
