From patchwork Sat Apr 13 00:02:02 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Burgess X-Patchwork-Id: 32277 Received: (qmail 127366 invoked by alias); 13 Apr 2019 00:02:12 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 127259 invoked by uid 89); 13 Apr 2019 00:02:09 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-24.8 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.1 spammy=UD:dwarf2read.c, dwarf2readc, dwarf2read.c X-HELO: mail-wm1-f68.google.com Received: from mail-wm1-f68.google.com (HELO mail-wm1-f68.google.com) (209.85.128.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 13 Apr 2019 00:02:07 +0000 Received: by mail-wm1-f68.google.com with SMTP id z11so13248203wmi.0 for ; Fri, 12 Apr 2019 17:02:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=usPmxgFWhIKk3q+kUglXqAu131w8PJpwQUmOy9FObQk=; b=djfVQDA7Z+dH+MsKApdMl980PwRQlopZYTAwLJJ4H5X1MbdAqf5RxoTSoal29g+ueB CBvbM+2s/gLipC/BjhziLh27MzoZALkxcZydNd+vcfDiELguO8sQZ9qN78jO79LaMkF1 AqBHglt0KwOKTxXZYTxL+bfta9JuijcldAQAFWCRnedFwQCIO3NbOKDnNDKWKes9VcN7 g0ignFhpmUSs/3PfRPDiiwLLT8LDcPcDKRncQ03tz2MUjPYhlUWS/cRKG8ik0T4pcvVz otQqPFgVsiIvWc90pO5KU3HL5s3MWbBLUApEnCYFmgVladNWVHEIeJ6lLHcEfRoWSEPE GAEw== Return-Path: Received: from localhost (host86-164-133-98.range86-164.btcentralplus.com. [86.164.133.98]) by smtp.gmail.com with ESMTPSA id x18sm60987336wrw.14.2019.04.12.17.02.03 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 12 Apr 2019 17:02:03 -0700 (PDT) Date: Sat, 13 Apr 2019 01:02:02 +0100 From: Andrew Burgess To: Sergio Durigan Junior Cc: gdb-patches@sourceware.org, Richard Bunt Subject: Re: New FAIL on gdb.base/complex-parts.exp - unix/-m32 (was: Re: [PATCH 1/8] gdb: Add $_cimag and $_creal internal functions) Message-ID: <20190413000202.GF2737@embecosm.com> References: <854230b716fa6838bd2d8e73f1fd2d342a7a75ed.1552913183.git.andrew.burgess@embecosm.com> <87ftqndlb6.fsf_-_@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87ftqndlb6.fsf_-_@redhat.com> X-Fortune: Vote for ME -- I'm well-tapered, half-cocked, ill-conceived and TAX-DEFERRED! X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes * Sergio Durigan Junior [2019-04-12 16:23:57 -0400]: > On Monday, March 18 2019, Andrew Burgess wrote: > > > Add two new internal functions $_cimag and $_creal that extract the > > imaginary and real parts of a complex value. > [...] > > Hi Andrew, > > The new testcase gdb.base/complex-parts.exp has one new FAIL when > testing x86_64 GDB against unix/-m32. I.e.: > > make check-gdb TESTS=gdb.base/complex-parts.exp RUNTESTFLAGS='--target_board unix/-m32' > > Here's what I'm seeing: > > ptype $ > type = > (gdb) FAIL: gdb.base/complex-parts.exp: ptype $ > ... > ptype $ > type = > (gdb) FAIL: gdb.base/complex-parts.exp: ptype $ > > The BuildBot run: > > https://gdb-build.sergiodj.net/builders/Fedora-x86_64-m32/builds/12210 > > The logs: > > https://gdb-build.sergiodj.net/results/Fedora-x86_64-m32/8b/8bdc16587e26100282094c8eaa8e83180ba57afd/ > > Let me know if you need help investigating this. Thanks for pointing this out. I've pushed the patch below to resolve this issue. Thanks, Andrew --- [PATCH] gdb: Fix failure in gdb.base/complex-parts.exp for x86-32 The x86-32 ABI specifies 96-bit long double, this was causing a failure on the test gdb.base/complex-parts.exp. The problem is that GDB tries to find a builtin floating point type of the correct size in order to reuse the name of that type as the name for the components of the complex type being built. Previously GDB was only aware of floating point types sized 32, 64, or 128 bits. This patch teaches GDB how to handle 96 bit floating point type. gdb/ChangeLog: * dwarf2read.c (dwarf2_init_complex_target_type): Handle complex target types of size 96-bits, add some additional comments, and check that the builtin type we found was the correct size. --- gdb/ChangeLog | 6 ++++++ gdb/dwarf2read.c | 10 ++++++++++ 2 files changed, 16 insertions(+) diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c index b718192cb12..0873028e438 100644 --- a/gdb/dwarf2read.c +++ b/gdb/dwarf2read.c @@ -17546,6 +17546,9 @@ dwarf2_init_complex_target_type (struct dwarf2_cu *cu, gdbarch *gdbarch = get_objfile_arch (objfile); struct type *tt = nullptr; + /* Try to find a suitable floating point builtin type of size BITS. + We're going to use the name of this type as the name for the complex + target type that we are about to create. */ switch (bits) { case 32: @@ -17554,11 +17557,18 @@ dwarf2_init_complex_target_type (struct dwarf2_cu *cu, case 64: tt = builtin_type (gdbarch)->builtin_double; break; + case 96: /* The x86-32 ABI specifies 96-bit long double. */ case 128: tt = builtin_type (gdbarch)->builtin_long_double; break; } + /* If the type we found doesn't match the size we were looking for, then + pretend we didn't find a type at all, the complex target type we + create will then be nameless. */ + if (TYPE_LENGTH (tt) * TARGET_CHAR_BIT != bits) + tt = nullptr; + const char *name = (tt == nullptr) ? nullptr : TYPE_NAME (tt); return dwarf2_init_float_type (objfile, bits, name, name_hint); }