From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3053 invoked by alias); 30 Apr 2007 13:03:43 -0000 Received: (qmail 3041 invoked by uid 22791); 30 Apr 2007 13:03:40 -0000 X-Spam-Check-By: sourceware.org Received: from igw2.br.ibm.com (HELO igw2.br.ibm.com) (32.104.18.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 30 Apr 2007 14:03:38 +0100 Received: from mailhub1.br.ibm.com (mailhub1 [9.18.232.109]) by igw2.br.ibm.com (Postfix) with ESMTP id 1DAF25BE03 for ; Mon, 30 Apr 2007 09:56:22 -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 l3UD3YBd1110124 for ; Mon, 30 Apr 2007 10:03:34 -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 l3UD2Slh017697 for ; Mon, 30 Apr 2007 10:02:28 -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 l3UD2RG9017674; Mon, 30 Apr 2007 10:02:28 -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: Ulrich Weigand Cc: Daniel Jacobowitz , gdb-patches ml In-Reply-To: <200704301227.l3UCRhMP024148@d12av02.megacenter.de.ibm.com> References: <200704301227.l3UCRhMP024148@d12av02.megacenter.de.ibm.com> Content-Type: text/plain Date: Mon, 30 Apr 2007 13:08:00 -0000 Message-Id: <1177938211.15264.2.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/msg00408.txt.bz2 > No, it isn't. How should GDB recognize the difference? Doesn't DWARF provide information about this on build time? > 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? Maybe that's the case. Alignment purposes? Regards, Luis