From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27718 invoked by alias); 28 Apr 2007 23:45:27 -0000 Received: (qmail 27706 invoked by uid 22791); 28 Apr 2007 23:45:26 -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; Sun, 29 Apr 2007 00:45:24 +0100 Received: from mailhub3.br.ibm.com (mailhub3 [9.18.232.110]) by igw1.br.ibm.com (Postfix) with ESMTP id 7686814804A for ; Sat, 28 Apr 2007 20:34:37 -0300 (BRT) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by mailhub3.br.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l3SNjLRb1478726 for ; Sat, 28 Apr 2007 20:45:21 -0300 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l3SNhJ7j001373 for ; Sat, 28 Apr 2007 20:43:20 -0300 Received: from [9.18.198.122] ([9.18.198.122]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l3SNhHwU001358; Sat, 28 Apr 2007 20:43:19 -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: <20070428162752.GA13329@caradoc.them.org> References: <20070428140823.GA31111@caradoc.them.org> <200704281624.l3SGOEJZ032044@d12av02.megacenter.de.ibm.com> <20070428162752.GA13329@caradoc.them.org> Content-Type: text/plain Date: Sat, 28 Apr 2007 23:47:00 -0000 Message-Id: <1177803916.6280.64.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-04/txt/msg00391.txt.bz2 Isn't GDB currently able to detect the type length in runtime in order to correctly print those values? With this modification i've noticed that GDB cuts the extra precision bytes for a binary built with -mlong-double-64, while printing the value with the total avaiable precision when it's built with -mlong-double-128. Regards, Luis On Sat, 2007-04-28 at 12:27 -0400, Daniel Jacobowitz wrote: > On Sat, Apr 28, 2007 at 06:24:14PM +0200, Ulrich Weigand wrote: > > We have the same situation on s390, where we switched from 64-bit to > > 128-bit long double a while ago. Like PowerPC, there is currently no > > way to recognize how a binary was built ... > > > > While an ABI marker might be a good idea in the future, we're stuck > > with the situation right now that many unmarked 128-bit long double > > binaries are already out there (e.g. all of SLES 10 and RHEL 5), > > and we really should be able to debug those properly. > > > > Thus I'm wondering whether we shouldn't have a reasonable default > > for unmarked binaries, presumably based on the system compiler > > defaults detected at configure time for native builds, and then > > provide a command allowing the user to override that default? > > Well, that's pretty much what I did for our customer who reported the > equivalent problem with PowerPC -msoft-float; except instead of > detecting it at configure time I added a manual configure option > (since this was for a cross-debugger). > > But it doesn't really scale... I'm open to better ideas... >