Message ID | m3a85b3fej.fsf@oc1027705133.ibm.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 61631 invoked by alias); 13 Jun 2017 18:34:50 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 61581 invoked by uid 89); 13 Jun 2017 18:34:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.4 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_LAZY_DOMAIN_SECURITY, KHOP_DYNAMIC, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy= X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 13 Jun 2017 18:34:48 +0000 Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v5DIXsP0186164 for <gdb-patches@sourceware.org>; Tue, 13 Jun 2017 14:34:51 -0400 Received: from e06smtp10.uk.ibm.com (e06smtp10.uk.ibm.com [195.75.94.106]) by mx0b-001b2d01.pphosted.com with ESMTP id 2b2kbue6eu-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for <gdb-patches@sourceware.org>; Tue, 13 Jun 2017 14:34:51 -0400 Received: from localhost by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <gdb-patches@sourceware.org> from <arnez@linux.vnet.ibm.com>; Tue, 13 Jun 2017 19:34:49 +0100 Received: from b06cxnps4074.portsmouth.uk.ibm.com (9.149.109.196) by e06smtp10.uk.ibm.com (192.168.101.140) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 13 Jun 2017 19:34:46 +0100 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v5DIYkqw36307168 for <gdb-patches@sourceware.org>; Tue, 13 Jun 2017 18:34:46 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id AABC5A404D for <gdb-patches@sourceware.org>; Tue, 13 Jun 2017 19:32:40 +0100 (BST) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 90616A4040 for <gdb-patches@sourceware.org>; Tue, 13 Jun 2017 19:32:40 +0100 (BST) Received: from oc1027705133.ibm.com (unknown [9.152.212.151]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTPS for <gdb-patches@sourceware.org>; Tue, 13 Jun 2017 19:32:40 +0100 (BST) From: Andreas Arnez <arnez@linux.vnet.ibm.com> To: gdb-patches@sourceware.org Subject: [PATCH] Fix register selection in var-access.exp Date: Tue, 13 Jun 2017 20:34:44 +0200 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 x-cbid: 17061318-0040-0000-0000-000003A94093 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17061318-0041-0000-0000-000025A235A9 Message-Id: <m3a85b3fej.fsf@oc1027705133.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-13_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706130319 X-IsSubscribed: yes |
Commit Message
Andreas Arnez
June 13, 2017, 6:34 p.m. UTC
The new test var-access.exp causes FAILs on i686. This is because the test chooses the wrong name for DWARF register number 1: It uses "edx" (which corresponds to DWARF register number 2), but should have used "ecx" instead. Also, the current logic in var-access.exp does not correctly distinguish between a 64-bit and a 32-bit program on an x86-64 target. It uses the 64-bit register names for both. These problems are fixed. In order to address the latter, the convenience macros is_*_target are exploited where appropriate. gdb/testsuite/ChangeLog: * gdb.dwarf2/var-access.exp: Use register name ecx instead of edx on 32-bit x86 targets. Exploit is_*_target macros where appropriate. --- gdb/testsuite/gdb.dwarf2/var-access.exp | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
Comments
On 2017-06-13 20:34, Andreas Arnez wrote: > The new test var-access.exp causes FAILs on i686. This is because the > test chooses the wrong name for DWARF register number 1: It uses > "edx" (which corresponds to DWARF register number 2), but should have > used > "ecx" instead. > > Also, the current logic in var-access.exp does not correctly > distinguish > between a 64-bit and a 32-bit program on an x86-64 target. It uses the > 64-bit register names for both. > > These problems are fixed. In order to address the latter, the > convenience > macros is_*_target are exploited where appropriate. > > gdb/testsuite/ChangeLog: > > * gdb.dwarf2/var-access.exp: Use register name ecx instead of edx > on 32-bit x86 targets. Exploit is_*_target macros where > appropriate. > --- > gdb/testsuite/gdb.dwarf2/var-access.exp | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/gdb/testsuite/gdb.dwarf2/var-access.exp > b/gdb/testsuite/gdb.dwarf2/var-access.exp > index 157a96c..96c54e7 100644 > --- a/gdb/testsuite/gdb.dwarf2/var-access.exp > +++ b/gdb/testsuite/gdb.dwarf2/var-access.exp > @@ -28,16 +28,16 @@ if {![dwarf2_support]} { > > set dwarf_regnum {0 1} > > -if { [istarget "aarch64*-*-*"] } { > +if { [is_aarch64_target] } { > set regname {x0 x1} > -} elseif { [istarget "arm*-*-*"] > +} elseif { [is_aarch32_target] > || [istarget "s390*-*-*" ] > || [istarget "powerpc*-*-*"] > || [istarget "rs6000*-*-aix*"] } { > set regname {r0 r1} > -} elseif { [istarget "i?86-*-*"] } { > - set regname {eax edx} > -} elseif { [istarget "x86_64-*-*"] } { > +} elseif { [is_x86_like_target] } { > + set regname {eax ecx} > +} elseif { [is_amd64_regs_target] } { > set regname {rax rdx} > } else { > verbose "Skipping tests for accessing DWARF-described variables." The patch LGTM. However could you (or somebody else) explain this to me? The doc of is_amd64_regs_target says: 2465 # Return 1 if target has x86_64 registers - either amd64 or x32. 2466 # x32 target identifies as x86_64-*-linux*, therefore it cannot be determined 2467 # just from the target string. If x32 identifies as x86_64-something and that procedure should return true when testing with x32 and x86_64/amd64, why can't we test the target string for x86_64-*?
On 06/13/2017 09:33 PM, Simon Marchi wrote: > However could you (or somebody else) explain this to me? The doc of > is_amd64_regs_target says: > > 2465 # Return 1 if target has x86_64 registers - either amd64 or x32. > 2466 # x32 target identifies as x86_64-*-linux*, therefore it cannot be > determined > 2467 # just from the target string. > > If x32 identifies as x86_64-something and that procedure should return > true when testing with x32 and x86_64/amd64, why can't we test the > target string for x86_64-*? Some vendors build --target i686-* toolchains, and then use -m64 to target the 64-bit multilib. Thanks, Pedro Alves
On Tue, Jun 13 2017, Pedro Alves wrote: > On 06/13/2017 09:33 PM, Simon Marchi wrote: > >> However could you (or somebody else) explain this to me? The doc of >> is_amd64_regs_target says: >> >> 2465 # Return 1 if target has x86_64 registers - either amd64 or x32. >> 2466 # x32 target identifies as x86_64-*-linux*, therefore it cannot be >> determined >> 2467 # just from the target string. >> >> If x32 identifies as x86_64-something and that procedure should return >> true when testing with x32 and x86_64/amd64, why can't we test the >> target string for x86_64-*? > > Some vendors build --target i686-* toolchains, and then > use -m64 to target the 64-bit multilib. Hm, I wasn't aware of that. In addition, even on an x86_64-* target, -m32 could be in effect. IMHO the comment is indeed misleading, but I'd rather leave it to someone who actually knows all the various x86/amd64 targets and ABIs to fix it. As this discussion is unrelated to the fix itself and the fix was approved already, I pushed it now. Thanks, Andreas
diff --git a/gdb/testsuite/gdb.dwarf2/var-access.exp b/gdb/testsuite/gdb.dwarf2/var-access.exp index 157a96c..96c54e7 100644 --- a/gdb/testsuite/gdb.dwarf2/var-access.exp +++ b/gdb/testsuite/gdb.dwarf2/var-access.exp @@ -28,16 +28,16 @@ if {![dwarf2_support]} { set dwarf_regnum {0 1} -if { [istarget "aarch64*-*-*"] } { +if { [is_aarch64_target] } { set regname {x0 x1} -} elseif { [istarget "arm*-*-*"] +} elseif { [is_aarch32_target] || [istarget "s390*-*-*" ] || [istarget "powerpc*-*-*"] || [istarget "rs6000*-*-aix*"] } { set regname {r0 r1} -} elseif { [istarget "i?86-*-*"] } { - set regname {eax edx} -} elseif { [istarget "x86_64-*-*"] } { +} elseif { [is_x86_like_target] } { + set regname {eax ecx} +} elseif { [is_amd64_regs_target] } { set regname {rax rdx} } else { verbose "Skipping tests for accessing DWARF-described variables."