From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4712 invoked by alias); 31 Aug 2007 18:15:20 -0000 Received: (qmail 4704 invoked by uid 22791); 31 Aug 2007 18:15:19 -0000 X-Spam-Check-By: sourceware.org Received: from igw1.br.ibm.com (HELO igw1.br.ibm.com) (32.104.18.24) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 31 Aug 2007 18:15:10 +0000 Received: from mailhub3.br.ibm.com (mailhub3 [9.18.232.110]) by igw1.br.ibm.com (Postfix) with ESMTP id D17B11481B8 for ; Fri, 31 Aug 2007 14:57:40 -0300 (BRT) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by mailhub3.br.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l7VIF62W1773636 for ; Fri, 31 Aug 2007 15:15:06 -0300 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l7VIF6bb009584 for ; Fri, 31 Aug 2007 15:15:06 -0300 Received: from [9.18.238.24] ([9.18.238.24]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l7VIF4qu009411; Fri, 31 Aug 2007 15:15:06 -0300 Subject: Re: [RFC] Detecting and printing 128-bit long double values for PPC From: Luis Machado Reply-To: luisgpm@linux.vnet.ibm.com To: Daniel Jacobowitz Cc: Ulrich Weigand , gdb-patches ml In-Reply-To: <20070506221707.GA29437@caradoc.them.org> References: <20070430135259.GA7430@caradoc.them.org> <200705062136.l46La00Q029476@d12av02.megacenter.de.ibm.com> <20070506221707.GA29437@caradoc.them.org> Content-Type: text/plain Date: Fri, 31 Aug 2007 18:15:00 -0000 Message-Id: <1188584103.4398.4.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2007-08/txt/msg00556.txt.bz2 On Sun, 2007-05-06 at 18:17 -0400, Daniel Jacobowitz wrote: > On Sun, May 06, 2007 at 11:36:00PM +0200, Ulrich Weigand wrote: > > Under the circumstances, I'd argue we should just change the built-in > > type to 128-bit, and make sure that binaries with a DWARF-2 reported > > "long double" fundamental type of 64-bit still use the proper floating > > point format info for that type. > > > > Anything I'm missing here? > > Sounds reasonable to me. Bringing back the topic. The patch is handling those types as 128-bit in length by default. Depending on the dwarf info, gdb switches to either 64-bit or 128-bit during printing. Isn't it right? Maybe i'm missing something regarding GDB's built-in types for long doubles. Regards, -- Luis Machado IBM Linux Technology Center e-mail: luisgpm@linux.vnet.ibm.com