From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 343 invoked by alias); 30 Apr 2007 13:44:29 -0000 Received: (qmail 330 invoked by uid 22791); 30 Apr 2007 13:44:27 -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:44:25 +0100 Received: from mailhub1.br.ibm.com (mailhub1 [9.18.232.109]) by igw1.br.ibm.com (Postfix) with ESMTP id 4FB311480DD for ; Mon, 30 Apr 2007 10:33:33 -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 l3UDiMTd1355776 for ; Mon, 30 Apr 2007 10:44:22 -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 l3UDhG4A015654 for ; Mon, 30 Apr 2007 10:43:17 -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 l3UDhFxS015617; Mon, 30 Apr 2007 10:43:16 -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: <20070430131616.GB25539@caradoc.them.org> References: <1177803916.6280.64.camel@localhost> <200704301227.l3UCRhMP024148@d12av02.megacenter.de.ibm.com> <20070430123432.GA30827@caradoc.them.org> <1177938530.15264.9.camel@localhost> <20070430131616.GB25539@caradoc.them.org> Content-Type: text/plain Date: Mon, 30 Apr 2007 13:51:00 -0000 Message-Id: <1177940660.15264.23.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/msg00417.txt.bz2 > This is "the ABI-defined long double type", which GDB distinguishes > from "the debug info describing long double". I suppose you could > come up with a way to distinguish binaries based on what their debug > info has to say about it, if it mentions long double anywhere. The idea could be that in case a different type is defined in the debug info than it's in the DWARF info, GDB would stick with what the debug info says instead. But then we would rely on debugging info for performing type identification. What about debugging running processes that do not have explicit debug info? Regards, Luis