From: Andrew Burgess <andrew.burgess@embecosm.com>
To: gdb-patches@sourceware.org
Cc: Andrew Burgess <andrew.burgess@embecosm.com>
Subject: [PATCH 2/2] gdb: Fix testsuite issue in gdb.arch/amd64-disp-step-avx.exp
Date: Thu, 22 Mar 2018 12:57:00 -0000 [thread overview]
Message-ID: <963bfa7c7483c4c907f4a63e9588b243845c8acd.1521722330.git.andrew.burgess@embecosm.com> (raw)
In-Reply-To: <cover.1521722330.git.andrew.burgess@embecosm.com>
In-Reply-To: <cover.1521722330.git.andrew.burgess@embecosm.com>
This test starts up and confirms that $xmm0 has the value 0, it then
modifies $xmm0 (in the inferior) and confirms that the new value can
be read (in GDB).
On some machines I was noticing that this test would occasionally
fail, and on investigation I believe that the reason for this is that
the test is linked as a dynamically linked executable and makes use of
the system libraries during startup. The reason that this causes
problems is that both the runtime linker and the startup code run
before main can, and do (on at least some platforms) make use of the
XMM registers.
In this commit I modify the test program slightly to allow it to be
linked statically, without using the startup libraries. Now by the
time GDB reaches the symbol main then we have only executed one 'nop'
instruction, and the XMM registers will all have the value 0. I've
extended the existing check in the test script to cover $xmm0 through
to $xmm15 (originally only $xmm0 was checked).
The test program is still linked against libc in order that we can
call the exit function, however, we now call _exit rather than exit in
order to avoid all of the usual cleanup that exit does. This clean up
tries to tear down things that are usually setup during the startup
code, but now this isn't called calling exit will just result in a
crash.
gdb/testsuite/ChangeLog:
* gdb.arch/amd64-disp-step-avx.S: Add '_start' label.
(done): Call '_exit' not 'exit' to avoid atexit handlers.
* gdb.arch/amd64-disp-step-avx.exp: Pass -static, and
-nostartfiles when compiling the test. Confirm that all registers
xmm0 to xmm15 are initially 0.
---
gdb/testsuite/ChangeLog | 8 ++++++++
gdb/testsuite/gdb.arch/amd64-disp-step-avx.S | 8 +++++---
gdb/testsuite/gdb.arch/amd64-disp-step-avx.exp | 12 ++++++++----
3 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/gdb/testsuite/gdb.arch/amd64-disp-step-avx.S b/gdb/testsuite/gdb.arch/amd64-disp-step-avx.S
index b56a552f6e6..1c06ceebab3 100644
--- a/gdb/testsuite/gdb.arch/amd64-disp-step-avx.S
+++ b/gdb/testsuite/gdb.arch/amd64-disp-step-avx.S
@@ -20,9 +20,11 @@
.text
- .global main
-main:
+ .global _start,main
+_start:
nop
+main:
+ nop
/***********************************************/
@@ -59,7 +61,7 @@ ro_var:
done:
mov $0,%rdi
- call exit
+ call _exit
hlt
/* RIP-relative data for VEX3 test above. */
diff --git a/gdb/testsuite/gdb.arch/amd64-disp-step-avx.exp b/gdb/testsuite/gdb.arch/amd64-disp-step-avx.exp
index 362ed7b7b3a..d25f9692360 100644
--- a/gdb/testsuite/gdb.arch/amd64-disp-step-avx.exp
+++ b/gdb/testsuite/gdb.arch/amd64-disp-step-avx.exp
@@ -25,8 +25,10 @@ if { ![istarget x86_64-*-* ] || ![is_lp64_target] } {
standard_testfile .S
-if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile} \
- [list debug]] } {
+set options [list debug \
+ additional_flags=-static \
+ additional_flags=-nostartfiles]
+if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile} $options] } {
return -1
}
@@ -103,8 +105,10 @@ proc disp_step_func { func } {
with_test_prefix "vex2" {
# This case writes to the 'xmm0' register. Confirm the register's
# value is what we believe it is before the AVX instruction runs.
- gdb_test "p /x \$xmm0.uint128" " = 0x0" \
- "xmm0 has expected value before"
+ for {set i 0 } { $i < 16 } { incr i } {
+ gdb_test "p /x \$xmm${i}.uint128" " = 0x0" \
+ "xmm${i} has expected value before"
+ }
disp_step_func "test_rip_vex2"
--
2.14.3
next prev parent reply other threads:[~2018-03-22 12:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-22 12:57 [PATCH 0/2] Test fix in gdb.arch/* tests Andrew Burgess
2018-03-22 12:57 ` Andrew Burgess [this message]
2018-03-22 13:44 ` [PATCH 2/2] gdb: Fix testsuite issue in gdb.arch/amd64-disp-step-avx.exp Pedro Alves
2018-03-22 23:01 ` Andrew Burgess
2018-03-23 10:13 ` Pedro Alves
2018-03-22 12:57 ` [PATCH 1/2] gdb: Minor cleanup in some gdb.arch/* tests Andrew Burgess
2018-03-22 13:51 ` Pedro Alves
2018-03-22 22:59 ` Andrew Burgess
2018-03-23 10:13 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=963bfa7c7483c4c907f4a63e9588b243845c8acd.1521722330.git.andrew.burgess@embecosm.com \
--to=andrew.burgess@embecosm.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox