From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26840 invoked by alias); 30 Apr 2007 12:34:39 -0000 Received: (qmail 26830 invoked by uid 22791); 30 Apr 2007 12:34:38 -0000 X-Spam-Check-By: sourceware.org Received: from return.false.org (HELO return.false.org) (66.207.162.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 30 Apr 2007 13:34:37 +0100 Received: from return.false.org (localhost [127.0.0.1]) by return.false.org (Postfix) with ESMTP id C6BBB4B26F; Mon, 30 Apr 2007 07:34:35 -0500 (CDT) Received: from caradoc.them.org (dsl093-172-095.pit1.dsl.speakeasy.net [66.93.172.95]) by return.false.org (Postfix) with ESMTP id 723C24B26D; Mon, 30 Apr 2007 07:34:33 -0500 (CDT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1HiV5M-00019u-O7; Mon, 30 Apr 2007 08:34:32 -0400 Date: Mon, 30 Apr 2007 12:41:00 -0000 From: Daniel Jacobowitz To: Ulrich Weigand Cc: luisgpm@linux.vnet.ibm.com, gdb-patches ml Subject: Re: [RFC] Detecting and printing 128-bit long double values for PPC Message-ID: <20070430123432.GA30827@caradoc.them.org> Mail-Followup-To: Ulrich Weigand , luisgpm@linux.vnet.ibm.com, gdb-patches ml References: <1177803916.6280.64.camel@localhost> <200704301227.l3UCRhMP024148@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200704301227.l3UCRhMP024148@d12av02.megacenter.de.ibm.com> User-Agent: Mutt/1.5.15 (2007-04-09) 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/msg00405.txt.bz2 On Mon, Apr 30, 2007 at 02:27:43PM +0200, Ulrich Weigand wrote: > Luis Machado wrote: > > > Isn't GDB currently able to detect the type length in runtime in order > > to correctly print those values? > > No, it isn't. How should GDB recognize the difference? > > > 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. > > That's interesting. GDB will always read in 16 bytes after your > modification -- maybe the binary you're building with -mlong-double-64 > happens to have zeros after the "long double" variable your're reading? GDB will always read 16 bytes when it uses its built in notion of "long double". But if it gets the type from DWARF info, then it will be an eight byte floating point type, and I bet GDB is automatically handling it as a double. That means that the patch is still incorrect, but the consequences of getting this wrong are not the immediately obvious ones. I don't know if saying (long double) in the command line is going to use the type from debug info or from the gdbarch; our handling of base types has always confused me somewhat. -- Daniel Jacobowitz CodeSourcery