From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9488 invoked by alias); 31 Aug 2007 18:27:16 -0000 Received: (qmail 9480 invoked by uid 22791); 31 Aug 2007 18:27:15 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 31 Aug 2007 18:27:08 +0000 Received: (qmail 17677 invoked from network); 31 Aug 2007 18:27:06 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 31 Aug 2007 18:27:06 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.63) (envelope-from ) id 1IRBCz-0001nY-Ic; Fri, 31 Aug 2007 18:27:05 +0000 Date: Fri, 31 Aug 2007 18:27:00 -0000 From: "Joseph S. Myers" To: Luis Machado cc: Daniel Jacobowitz , Ulrich Weigand , gdb-patches ml Subject: Re: [RFC] Detecting and printing 128-bit long double values for PPC In-Reply-To: <1188584103.4398.4.camel@localhost> Message-ID: References: <20070430135259.GA7430@caradoc.them.org> <200705062136.l46La00Q029476@d12av02.megacenter.de.ibm.com> <20070506221707.GA29437@caradoc.them.org> <1188584103.4398.4.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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/msg00557.txt.bz2 On Fri, 31 Aug 2007, Luis Machado wrote: > 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. I have an alternative patch to add 128-bit IBM long double support to GDB that I'll submit once Daniel's patch to use object attributes to detect the soft-float ABI is in. My patch has nothing in common with the previous patch ; my conclusions were: * GDB handles floating point using the host's floating point types, using the widest one available as DOUBLEST. * It's OK (as you mention) for GDB's built-in "long double" to have the 128-bit format unconditionally, since the debug info will identify the sizes of the types actually used in the program being debugged. * However, GDB needs to get the host format right or not set gdb_host_long_double_format at all, so where that patch hardcodes it for powerpc64-*-* is wrong. * Setting the host format is only an optimization to avoid excess conversions where host and target formats are the same. * That patch will only work for the native case, because it has no code to decode IBM long doubles in other cases. * GDB needs to know the ABIs used for passing IBM long double arguments. So what I did was added proper IBM long double support to both libiberty and GDB, the patch doing the following: - Checking long doubles for validity according to gcc/config/rs6000/darwin-ldouble-format. - Converting IBM long doubles to host formats by converting each half and then adding. - Converting host doubles to IBM long double by putting 0 in the bottom half. - Converting host long doubles to IBM long double by converting to double, putting the result in the top half, and then (except for infinities) subtracting the result from the original value, converting the result of the subtraction to double and putting it in the bottom half. - Adding code to ppc-sysv-tdep.c to implement the ABIs for IBM long double arguments correctly. I did not do anything about host format for powerpc64; that needs autoconf detection. -- Joseph S. Myers joseph@codesourcery.com