Message ID | 1538034149-12136-2-git-send-email-markus.t.metzger@intel.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 16348 invoked by alias); 27 Sep 2018 07:44:01 -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 16163 invoked by uid 89); 27 Sep 2018 07:43:41 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-24.2 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_LAZY_DOMAIN_SECURITY autolearn=ham version=3.3.2 spammy=H*r:LOCAL X-HELO: mga18.intel.com Received: from mga18.intel.com (HELO mga18.intel.com) (134.134.136.126) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 27 Sep 2018 07:43:40 +0000 Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Sep 2018 00:43:38 -0700 Received: from irvmail001.ir.intel.com ([163.33.26.43]) by orsmga003.jf.intel.com with ESMTP; 27 Sep 2018 00:42:30 -0700 Received: from ulvlx001.iul.intel.com (ulvlx001.iul.intel.com [172.28.207.17]) by irvmail001.ir.intel.com (8.14.3/8.13.6/MailSET/Hub) with ESMTP id w8R7gTE7009026; Thu, 27 Sep 2018 08:42:29 +0100 Received: from ulvlx001.iul.intel.com (localhost [127.0.0.1]) by ulvlx001.iul.intel.com with ESMTP id w8R7gThY012431; Thu, 27 Sep 2018 09:42:29 +0200 Received: (from mmetzger@localhost) by ulvlx001.iul.intel.com with LOCAL id w8R7gTGd012427; Thu, 27 Sep 2018 09:42:29 +0200 From: Markus Metzger <markus.t.metzger@intel.com> To: gdb-patches@sourceware.org Subject: [PATCH] testsuite: fix is_amd64_regs_target Date: Thu, 27 Sep 2018 09:42:29 +0200 Message-Id: <1538034149-12136-2-git-send-email-markus.t.metzger@intel.com> In-Reply-To: <1538034149-12136-1-git-send-email-markus.t.metzger@intel.com> References: <1538034149-12136-1-git-send-email-markus.t.metzger@intel.com> X-IsSubscribed: yes |
Commit Message
Metzger, Markus T
Sept. 27, 2018, 7:42 a.m. UTC
Commit c221b2f Testsuite: Add gdb_can_simple_compile changed the source file name extension of the test program from .s to .c resulting in compile fails. This, in turn, causes is_amd64_regs_target checks to fail. In gdb.btrace/tailcall.exp and others, this causes the wrong source file to be picked and the test to fail on 64-bit targets. Change the test source from an assembly program to a C program using inline assembly. There is a similar case for is_aarch32_target that I have not touched as I would not be able to test my changes. 2018-09-27 Markus Metzger <markus.t.metzger@intel.com> testsuite/ * lib/gdb.exp (is_amd64_regs_target): Change assembly to C inline assembly. --- gdb/testsuite/lib/gdb.exp | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-)
Comments
>>>>> "Markus" == Markus Metzger <markus.t.metzger@intel.com> writes:
Markus> testsuite/
Markus> * lib/gdb.exp (is_amd64_regs_target): Change assembly to C inline
Markus> assembly.
Markus> - set list {}
Markus> - foreach reg \
Markus> - {rax rbx rcx rdx rsi rdi rbp rsp r8 r9 r10 r11 r12 r13 r14 r15} {
Markus> - lappend list "\tincq %$reg"
Markus> - }
Markus> + return [gdb_can_simple_compile is_amd64_regs_target {
Markus> + int main (void) {
Markus> + asm ("incq %rax");
Markus> + asm ("incq %r15");
I suppose reducing the number of registers tested doesn't materially
affect the test.
Assuming that's the case, this is ok. Thank you.
Tom
Hello Tom, Thanks for your review. > Markus> - set list {} > Markus> - foreach reg \ > Markus> - {rax rbx rcx rdx rsi rdi rbp rsp r8 r9 r10 r11 r12 r13 r14 r15} { > Markus> - lappend list "\tincq %$reg" > Markus> - } > Markus> + return [gdb_can_simple_compile is_amd64_regs_target { > Markus> + int main (void) { > Markus> + asm ("incq %rax"); > Markus> + asm ("incq %r15"); > > I suppose reducing the number of registers tested doesn't materially affect the > test. That's my assumption, as well. We already checked the architecture so we know it is some x86 flavor. A single 64-bit register should suffice. The gdb.btrace suite passes on 32-bit and 64-bit including m32. I have not run the full suite since the problem was already seen on the gdb.btrace suite. Regards, Markus. Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
>>>>> "Markus" == Metzger, Markus T <markus.t.metzger@intel.com> writes:
Markus> That's my assumption, as well. We already checked the architecture so we know it
Markus> is some x86 flavor. A single 64-bit register should suffice.
I didn't see it go in, so I wanted to reiterate that I think it is ok.
Tom
On 2018-09-28 01:20 PM, Tom Tromey wrote: >>>>>> "Markus" == Metzger, Markus T <markus.t.metzger@intel.com> writes: > > Markus> That's my assumption, as well. We already checked the architecture so we know it > Markus> is some x86 flavor. A single 64-bit register should suffice. > > I didn't see it go in, so I wanted to reiterate that I think it is ok. > > Tom > Maybe I'm missing something obvious, but could one of you explain to me the comment of that proc, which is # Return 1 if target has x86_64 registers - either amd64 or x32. # x32 target identifies as x86_64-*-linux*, therefore it cannot be determined # just from the target string. If I understand correctly, is_amd64_regs_target should return 1 when using the x32 abi, as well as when using the standard amd64 abi. The comment says an x32 target has an x86_64-* triplet... so can't we just check the triplet, and return 1 if it's x86-64-*? Simon
On 09/28/2018 09:27 PM, Simon Marchi wrote: > Maybe I'm missing something obvious, but could one of you explain to me > the comment of that proc, which is > > # Return 1 if target has x86_64 registers - either amd64 or x32. > # x32 target identifies as x86_64-*-linux*, therefore it cannot be determined > # just from the target string. > > If I understand correctly, is_amd64_regs_target should return 1 when using the > x32 abi, as well as when using the standard amd64 abi. The comment says an x32 > target has an x86_64-* triplet... so can't we just check the triplet, and return > 1 if it's x86-64-*? No, because toolchains configured with i686-* triplets can also be used in combination with -mx32/-m64. Same for is_64_target, is_lp64_target, etc. Thanks, Pedro Alves
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp index f32abfedd52..1eea92298c4 100644 --- a/gdb/testsuite/lib/gdb.exp +++ b/gdb/testsuite/lib/gdb.exp @@ -2467,13 +2467,14 @@ gdb_caching_proc is_amd64_regs_target { return 0 } - set list {} - foreach reg \ - {rax rbx rcx rdx rsi rdi rbp rsp r8 r9 r10 r11 r12 r13 r14 r15} { - lappend list "\tincq %$reg" - } + return [gdb_can_simple_compile is_amd64_regs_target { + int main (void) { + asm ("incq %rax"); + asm ("incq %r15"); - return [gdb_can_simple_compile is_amd64_regs_target [join $list \n]] + return 0; + } + }] } # Return 1 if this target is an x86 or x86-64 with -m32.