From: Andreas Arnez <arnez@linux.vnet.ibm.com>
To: Doug Evans <dje@google.com>
Cc: Yao Qi <qiyaoltc@gmail.com>,
Joel Brobecker <brobecker@adacore.com>,
gdb-patches <gdb-patches@sourceware.org>
Subject: Re: Several regressions and we branch soon.
Date: Thu, 25 Jun 2015 18:00:00 -0000 [thread overview]
Message-ID: <87a8vnzmzy.fsf@br87z6lw.de.ibm.com> (raw)
In-Reply-To: <CADPb22TCA_uDCwLksVTo=2QB+OapBuPfAB2aSaok1ZdxDCU0Bw@mail.gmail.com> (Doug Evans's message of "Thu, 25 Jun 2015 08:34:14 -0500")
On Thu, Jun 25 2015, Doug Evans wrote:
> On Thu, Jun 25, 2015 at 3:21 AM, Andreas Arnez <arnez@linux.vnet.ibm.com> wrote:
>> On Wed, Jun 24 2015, Yao Qi wrote:
>>
>>> Doug Evans <dje@google.com> writes:
>>>
>>>> FAIL: gdb.base/gnu_vector.exp: call add_singlevecs
>>>
>>> I see this fail too,
>>> print add_singlevecs((char1) {6}, (int1) {12}, (double1) {24})^M
>>> ^M
>>> Program received signal SIGSEGV, Segmentation fault.^M
>>> 0x00000000004008ec in add_singlevecs (a=..., b=..., c=...) at ../../../../../binutils-gdb/gdb/testsuite/gdb.base/gnu_vector.c:132^M
>>> 132 return (double1) {a[0] + b[0] + c[0]};^M
>>> The program being debugged was signaled while in a function called from GDB.^M
>>> GDB remains in the frame where the signal was received.^M
>>> To change this behavior use "set unwindonsignal on".^M
>>> Evaluation of the expression containing the function^M
>>> (add_singlevecs) will be abandoned.^M
>>> When the function is done executing, GDB will silently stop.^M
>>> (gdb) FAIL: gdb.base/gnu_vector.exp: call add_singlevecs
>>
>> This is not a regression in GDB, but a new test uncovering GDB's missing
>> vector ABI support on x86_64. So for the branch I suggest to suppress
>> these new FAILs with gnu_vector.exp -- either in the test case or in the
>> test harness.
>
> Any reason to not mark them as K/XFAILs in the master branch?
> We should avoid adding new tests the we know are going to FAIL (*1).
> And indeed I see discussion in the submission about that.
> https://sourceware.org/ml/gdb-patches/2015-05/msg00319.html
> So we're good there.
Right, this was considered in the patch. But only what I've actually
seen fail in my testing is marked as KFAIL. Since more FAILs are
observed now, maybe we could mark them as KFAIL as well. Or skip them
altogether, like in the patch below. WDYT?
> The question remains though: why are these failing?
Good question. Apparently there are various problems with inferior
function calls on x86_64 when vector arguments and/or vector return
values are involved. I haven't analyzed this, and I'd rather leave that
to the x86_64 maintainers.
-- >8 --
Subject: [PATCH] gnu_vector.exp: Skip tests known to crash inferior on x86(_64)
From: Andreas Arnez <arnez@linux.vnet.ibm.com>
diff --git a/gdb/testsuite/gdb.base/gnu_vector.exp b/gdb/testsuite/gdb.base/gnu_vector.exp
index cf91fbb..885e2f2 100644
--- a/gdb/testsuite/gdb.base/gnu_vector.exp
+++ b/gdb/testsuite/gdb.base/gnu_vector.exp
@@ -189,13 +189,18 @@ gdb_test "print add_various_floatvecs(2, f4a, f4b)" "= \\{3, 6, 16, 20\\}" \
setup_kfail gdb/18537 "i?86-*-*" "x86_64-*-*"
gdb_test "print add_structvecs(i2, (struct just_int2)\{2*i2\}, (struct two_int2)\{3*i2, 4*i2\})" \
"= \\{i = \\{10, 20\\}\\}" "call add_structvecs"
+if { [istarget "i?86-*-*"] || [istarget "x86_64-*-*" ] } {
+ # The next test has been seen to crash the inferior on x86_64, so
+ # just stop here.
+ kfail gdb/18537 "skip remaining vector ABI tests on this arch"
+ return
+}
gdb_test "print add_singlevecs((char1) \{6\}, (int1) \{12\}, (double1) \{24\})" "= \\{42\\}" \
"call add_singlevecs"
# Test vector return value handling with "finish" and "return".
gdb_breakpoint "add_some_intvecs"
gdb_continue "add_some_intvecs"
-setup_kfail gdb/18537 "i?86-*-*" "x86_64-*-*"
gdb_test "finish" "Value returned is .* = \\{10, 20, 48, 72\\}" \
"finish shows vector return value"
gdb_continue "add_some_intvecs"
@@ -203,5 +208,4 @@ gdb_test "return (int4) \{4, 2, 7, 6\}" \
"#0 .* main .*" \
"set vector return value" \
"Make add_some_intvecs return now. .y or n.*" "y"
-setup_kfail gdb/18537 "i?86-*-*" "x86_64-*-*"
gdb_test "continue" "4 2 7 6\r\n.*" "verify vector return value"
next prev parent reply other threads:[~2015-06-25 18:00 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-23 18:31 Doug Evans
2015-06-23 18:55 ` Patrick Palka
2015-06-23 19:03 ` Doug Evans
2015-06-23 20:17 ` Keith Seitz
2015-06-23 20:53 ` Doug Evans
2015-06-23 21:45 ` Patrick Palka
2015-06-24 11:55 ` Yao Qi
2015-06-25 16:35 ` Tedeschi, Walfred
2015-07-01 8:49 ` Yao Qi
[not found] ` <AC542571535E904D8E8ADAE745D60B1944445D44@IRSMSX104.ger.corp.intel.com>
2015-07-01 9:30 ` Walfred Tedeschi
2015-07-02 10:09 ` Yao Qi
2015-07-02 15:34 ` Yao Qi
2015-07-02 16:19 ` [PATCH] Don't throw an error in "show mpx bound" implementation Patrick Palka
2015-07-06 9:31 ` Yao Qi
2015-06-24 10:21 ` Several regressions and we branch soon Yao Qi
[not found] ` <87lhf8yz90.fsf@br87z6lw.de.ibm.com>
2015-06-25 13:34 ` Doug Evans
2015-06-25 18:00 ` Andreas Arnez [this message]
2015-06-30 15:21 ` Yao Qi
2015-06-30 18:09 ` Andreas Arnez
2015-07-01 8:01 ` Yao Qi
2015-07-10 9:33 ` Yao Qi
2015-07-10 16:12 ` Andreas Arnez
2015-07-10 16:23 ` Ulrich Weigand
2015-07-20 15:08 ` Andreas Arnez
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=87a8vnzmzy.fsf@br87z6lw.de.ibm.com \
--to=arnez@linux.vnet.ibm.com \
--cc=brobecker@adacore.com \
--cc=dje@google.com \
--cc=gdb-patches@sourceware.org \
--cc=qiyaoltc@gmail.com \
/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