From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 88CB43858D35 for ; Fri, 5 Nov 2021 09:33:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 88CB43858D35 Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-137-9ZYc4N88PWqHgRcLFiQK3Q-1; Fri, 05 Nov 2021 05:33:03 -0400 X-MC-Unique: 9ZYc4N88PWqHgRcLFiQK3Q-1 Received: by mail-wm1-f69.google.com with SMTP id m18-20020a05600c3b1200b0033283ea5facso2526696wms.1 for ; Fri, 05 Nov 2021 02:33:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=MVO7n0/6Cu+h1+NH5ZC6547U0lflFN60JXwYcJk+Mrk=; b=nUF0U9yIoUtXv8gRaFuWPhLFMeJoDwAU4hizSx/aBHB2D2+uyuL/EsJlg+1jx+IVkZ mDYJcs2z3AdE6Kf52iVVi2fMLeq9uhW4li5wOR4cocebtp5O+03sIrUEqn6mBAtJP0jt WQtMKsGJeXUwTj3TmDyexmlvIAlzYrb4M6g7MMrZCiJkK1v6xJVAB4nZv9I4+Vg9b4/s HOQEBI6+hFGrt+wG3y0Rd2JQ+7wbKBCy9iz6OP5nRdgLMiti1aNDkzF/4ZPVSFURNS29 uyxr5VPS/nMhwoN+JWIr28kZ6OiobYBjW6xONF0aPkjGqQeyEdS4xkhnnhp29mfiVwAG wY0g== X-Gm-Message-State: AOAM533Q/w9kJy6MYu41TusBtik3LiGFwvql3sJlZrAy6QVjwFQD3Qot R5ZqrLxLo4ArxiRh0V8UfDXtsvjO2anvR/CVVmMWvtLt4+Gesf+pEl1DmcoH2+gQHgjsbKj7VWH aV6vRU3X4Fga8DuTduQBtJg== X-Received: by 2002:a7b:c8d5:: with SMTP id f21mr27533661wml.146.1636104782143; Fri, 05 Nov 2021 02:33:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxVxuxDZD5SCEKoE9hcnvyI0+QdNs+ee/HeURF2zitvV3NcjD4P7axEbBUt8IG+jiMRrB3W9g== X-Received: by 2002:a7b:c8d5:: with SMTP id f21mr27533648wml.146.1636104781993; Fri, 05 Nov 2021 02:33:01 -0700 (PDT) Received: from localhost (host86-166-129-255.range86-166.btcentralplus.com. [86.166.129.255]) by smtp.gmail.com with ESMTPSA id c5sm4214381wrd.13.2021.11.05.02.33.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Nov 2021 02:33:01 -0700 (PDT) Date: Fri, 5 Nov 2021 09:33:00 +0000 From: Andrew Burgess To: Tom de Vries Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] [gdb/testsuite] Fix gdb.arch/i386-avx.exp with clang Message-ID: <20211105093300.GG918204@redhat.com> References: <20211104135559.5875-1-tdevries@suse.de> MIME-Version: 1.0 In-Reply-To: <20211104135559.5875-1-tdevries@suse.de> X-Operating-System: Linux/5.8.18-100.fc31.x86_64 (x86_64) X-Uptime: 09:31:18 up 4 days, 4 min, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-10.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2021 09:33:08 -0000 * Tom de Vries via Gdb-patches [2021-11-04 14:55:59 +0100]: > When running test-case gdb.arch/i386-avx.exp with clang I ran into: > ... > (gdb) PASS: gdb.arch/i386-avx.exp: set first breakpoint in main > continue^M > Continuing.^M > ^M > Program received signal SIGSEGV, Segmentation fault.^M > 0x000000000040052b in main (argc=1, argv=0x7fffffffd3c8) at i386-avx.c:54^M > 54 asm ("vmovaps 0(%0), %%ymm0\n\t"^M > (gdb) FAIL: gdb.arch/i386-avx.exp: continue to breakpoint: \ > continue to first breakpoint in main > ... > > The problem is that the vmovaps insn requires an 256-bit (or 32-byte aligned > address), and it's only 16-byte aligned: > ... > (gdb) p /x $rax > $1 = 0x601030 > ... > > Fix this by copying to a sufficiently aligned address. > > Tested on x86_64-linux, with both gcc and clang. > --- > gdb/testsuite/gdb.arch/i386-avx.c | 28 +++++++++++++++++++++++++++- > 1 file changed, 27 insertions(+), 1 deletion(-) > > diff --git a/gdb/testsuite/gdb.arch/i386-avx.c b/gdb/testsuite/gdb.arch/i386-avx.c > index 4e938399a24..9b5323f9f76 100644 > --- a/gdb/testsuite/gdb.arch/i386-avx.c > +++ b/gdb/testsuite/gdb.arch/i386-avx.c > @@ -18,6 +18,9 @@ > along with this program. If not, see . */ > > #include > +#include > +#include > +#include > #include "nat/x86-cpuid.h" > > typedef struct { > @@ -25,7 +28,7 @@ typedef struct { > } v8sf_t; > > > -v8sf_t data[] = > +v8sf_t data_orig[] = I see the same problem. Did you consider using: /* Some useful comment .... */ v8sf_t data[] __attribute__ ((aligned(32))) = .... this seems to fix the problem on clang for me, and still works fine with gcc. Thanks, Andrew > { > { { 0.0, 0.125, 0.25, 0.375, 0.50, 0.625, 0.75, 0.875 } }, > { { 1.0, 1.125, 1.25, 1.375, 1.50, 1.625, 1.75, 1.875 } }, > @@ -47,10 +50,33 @@ v8sf_t data[] = > #endif > }; > > +float data_buf[sizeof (data_orig) * 2 / sizeof (float)]; > > int > main (int argc, char **argv) > { > + v8sf_t *data; > + > + /* Initialize data pointer. */ > + { > + float *p = data_buf; > + float *data_buf_end = &data_buf[sizeof (data_buf) / sizeof (*data_buf)]; > + while (((uintptr_t)p & 0x1f) != 0 > + && p < data_buf_end) > + p++; > + data = (v8sf_t *)p; > + } > + > + /* Check that data pointer is sufficiently aligned to use vmovaps. */ > + assert (((uintptr_t)data & 0x1f) == 0); > + > + /* Check that memcpy does not write out of bounds. */ > + assert ((void *)data + sizeof (data_orig) > + <= (void *)data_buf + sizeof (data_buf)); > + > + /* Initialize data contents. */ > + memcpy (data, data_orig, sizeof (data_orig)); > + > asm ("vmovaps 0(%0), %%ymm0\n\t" > "vmovaps 32(%0), %%ymm1\n\t" > "vmovaps 64(%0), %%ymm2\n\t" > > base-commit: edc77c591add0a9c7740a9ed9f7e40358bf65dbf > -- > 2.26.2 >