From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76265 invoked by alias); 10 Jul 2015 16:12:19 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 76254 invoked by uid 89); 10 Jul 2015 16:12:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: e06smtp12.uk.ibm.com Received: from e06smtp12.uk.ibm.com (HELO e06smtp12.uk.ibm.com) (195.75.94.108) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Fri, 10 Jul 2015 16:12:17 +0000 Received: from /spool/local by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 10 Jul 2015 17:12:14 +0100 Received: from d06dlp02.portsmouth.uk.ibm.com (9.149.20.14) by e06smtp12.uk.ibm.com (192.168.101.142) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 10 Jul 2015 17:12:12 +0100 X-MailFrom: arnez@linux.vnet.ibm.com X-RcptTo: gdb-patches@sourceware.org Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 480D42190046 for ; Fri, 10 Jul 2015 17:11:49 +0100 (BST) Received: from d06av08.portsmouth.uk.ibm.com (d06av08.portsmouth.uk.ibm.com [9.149.37.249]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t6AGCBvE38010956 for ; Fri, 10 Jul 2015 16:12:11 GMT Received: from d06av08.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av08.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t6AGCAxO032134 for ; Fri, 10 Jul 2015 10:12:11 -0600 Received: from br87z6lw.de.ibm.com (dyn-9-152-212-115.boeblingen.de.ibm.com [9.152.212.115]) by d06av08.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id t6AGCAee032113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA256 bits=256 verify=NO); Fri, 10 Jul 2015 10:12:10 -0600 From: Andreas Arnez To: Yao Qi Cc: Doug Evans , Joel Brobecker , Ulrich Weigand , gdb-patches Subject: Re: Several regressions and we branch soon. References: <86r3p1queo.fsf@gmail.com> <87lhf8yz90.fsf@br87z6lw.de.ibm.com> <87a8vnzmzy.fsf@br87z6lw.de.ibm.com> <86twtpp6i0.fsf@gmail.com> <87h9ppkr0d.fsf@br87z6lw.de.ibm.com> <86h9pcl5lc.fsf@gmail.com> Date: Fri, 10 Jul 2015 16:12:00 -0000 In-Reply-To: <86h9pcl5lc.fsf@gmail.com> (Yao Qi's message of "Fri, 10 Jul 2015 10:33:35 +0100") Message-ID: <87zj34j8kl.fsf@br87z6lw.de.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15071016-0009-0000-0000-000004CBA223 X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg00332.txt.bz2 On Fri, Jul 10 2015, Yao Qi wrote: > Andreas Arnez writes: > >> Subject: [PATCH] gnu_vector.exp: Skip infcall tests on x86/x86_64 >> >> Since the new KFAILs/KPASSs for the infcall tests on x86 and x86_64 >> targets generated unnecessary noise, this change skips them with >> UNSUPPORTED instead. > > Hi Andreas, > I still see some fails in gnu_vector.exp in various architectures, > > Here are some fails on ppc64be-m64, as I found from buildbot > https://www.sourceware.org/ml/gdb-testers/2015-q3/msg01198.html > > new FAIL: gdb.base/gnu_vector.exp: call add_some_intvecs > new FAIL: gdb.base/gnu_vector.exp: call add_various_floatvecs > new FAIL: gdb.base/gnu_vector.exp: finish shows vector return value > new FAIL: gdb.base/gnu_vector.exp: verify vector return value (the program exited) > > Does GDB support vector infcall on ppc64be? AFAIK, it should. However, on that system the compilation with "-mcpu=native" fails because GCC5 emits an ABI warning: gnu_vector.c:62:1: note: the layout of aggregates containing vectors with 4-byte alignment has changed in GCC 5 Then the test case falls back to compiling without an "-mcpu=" flag, so the FAILs occur with GCC's default machine options. I am not sure whether that is supposed to work with GDB. (Does anybody know?) Anyway, maybe we should add "-Wno-psabi" to the compile options. This will likely get rid of the (probably unimportant) FAILs above. > I checked the test result > on ppc64le https://www.sourceware.org/ml/gdb-testers/2015-q3/msg01201.html > but gnu_vector.exp isn't compiled successfully (due to old gcc?) this > case isn't compiled successfully on aix buildslave either. GCC5 on ppc64le emits the ABI warning even in absence of "-mcpu=". Again it should help to add "-Wno-psabi". > > I also see two fails on s390x from buildbot > https://www.sourceware.org/ml/gdb-testers/2015-q3/msg00957.html > > FAIL: gdb.base/gnu_vector.exp: finish shows vector return value > FAIL: gdb.base/gnu_vector.exp: verify vector return value (the program exited) > > IIUC, vector infcall should be supported on s390 GDB, right? Yes. But in this case no vector ABI is used, because that test machine does not have a vector facility and because -march=native is not supported by GCC (yet). Thus vector return values are not passed in vector registers, but according to RETURN_VALUE_STRUCT_CONVENTION. And then we hit the problem that displaying such return values is not supported by GDB: https://sourceware.org/bugzilla/show_bug.cgi?id=8549 Note that various other testsuite FAILs on s390 are due to non-displayable structure return values as well, e.g.: FAIL: gdb.ada/array_return.exp: value printed by finish of Create_Small Thus I have already been working on fixing that. > I also see some vector infcall fails on both arm and aarch64 too. What > GDB targets should support vector infcall? ppc64 (le and be) and s390? Sorry, I do not know. This question should better be addressed to the various architecture maintainers. Note that many architectures have *multiple* vector ABIs, depending on the level of hardware support available. So a complete answer to your question would be a filled-out table like this (where the examples are obviously completely made up): | architecture | vector ABI | infcall | "finish" | |--------------+------------+---------+----------| | foo | no HW | OK | bad ret | | | VX16 | broken | broken | | | VY32 | OK | OK | |--------------+------------+---------+----------| | bar | no HW | OK | OK | | | VBLURB | OK | OK | | | V-ng | unsupp | no ret | The s390 part currently looks like this: | architecture | vector ABI | infcall | "finish" | |--------------+---------------------+---------+----------| | s390x | no HW | OK | no ret | | | S390_VECTOR_ABI_128 | OK | OK | (1) Assuming that the vector return value fits in a vector register. > I am wondering we should only do the vector infcall tests on the > supported GDB targets, and skip for the rest of them. We could. On the other hand there is a difference from the usual "lacking support" case: Normally GDB tells the user about the lacking support. Here, GDB performs a bogus inferior function call instead, shows a wrong return value, or even crashes the inferior. This seems more like a bug than a missing feature to me. In my view, targets that can not perform vector ABI infcalls correctly should at least suppress the infcall and emit an appropriate error message. -- Andreas