From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12871 invoked by alias); 30 Apr 2007 13:08:59 -0000 Received: (qmail 12858 invoked by uid 22791); 30 Apr 2007 13:08:58 -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; Mon, 30 Apr 2007 14:08:55 +0100 Received: from mailhub1.br.ibm.com (mailhub1 [9.18.232.109]) by igw1.br.ibm.com (Postfix) with ESMTP id 27A8E1480FC for ; Mon, 30 Apr 2007 09:58:04 -0300 (BRT) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by mailhub1.br.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l3UD8qFx1359948 for ; Mon, 30 Apr 2007 10:08:53 -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 l3UD7l6t026767 for ; Mon, 30 Apr 2007 10:07:47 -0300 Received: from [9.18.238.71] ([9.18.238.71]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l3UD7jPm026741; Mon, 30 Apr 2007 10:07:47 -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: <20070430123432.GA30827@caradoc.them.org> References: <1177803916.6280.64.camel@localhost> <200704301227.l3UCRhMP024148@d12av02.megacenter.de.ibm.com> <20070430123432.GA30827@caradoc.them.org> Content-Type: text/plain Date: Mon, 30 Apr 2007 13:15:00 -0000 Message-Id: <1177938530.15264.9.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/msg00409.txt.bz2 > 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. Isn't the length of the data type supposed to be available from DWARF? Or this should still be included by the binaries that actually generate the DWARF info? Regards, Luis