From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13495 invoked by alias); 7 Mar 2004 20:19:09 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 13485 invoked from network); 7 Mar 2004 20:19:08 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.170.238) by sources.redhat.com with SMTP; 7 Mar 2004 20:19:08 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 056DC2B92; Sun, 7 Mar 2004 15:19:08 -0500 (EST) Message-ID: <404B83BC.1080100@gnu.org> Date: Fri, 19 Mar 2004 00:09:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Richard Henderson Cc: gdb-patches@gcc.gnu.org Subject: Re: [rfc] conditional 128-bit long double References: <20040307080658.GA18878@redhat.com> In-Reply-To: <20040307080658.GA18878@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00142.txt.bz2 Message-ID: <20040319000900.3bO-w_UUPteNLTFGhop2_9Yv4RHYPArtgP-mV9abOfE@z> > The only thing that would be better is if gdb could look up long double > in the debug info: GDB needs to come up in a sane state without debug info - stripped executable or even: $ gdb (gdb) print (long double) 1 * 2 so you can't rely on debug info. > but I have no idea if one could even think doing such a thing in gdb. > I expect to *never* have to handle applications with mismatched types, > as I'm planning to bump the libc version number before this is over. Won't you also want to brand the executable and object file? Without that it will be too wasy to link the wrong object file into the wrong executable. GDB handles ABI variants with OSABI sniffers that key off the brand. Andrew