From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2350 invoked by alias); 9 Nov 2007 01:26:28 -0000 Received: (qmail 2247 invoked by uid 22791); 9 Nov 2007 01:26:26 -0000 X-Spam-Check-By: sourceware.org Received: from mx10.gnu.org (HELO mx10.gnu.org) (199.232.76.166) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 09 Nov 2007 01:26:23 +0000 Received: from rock.gnat.com ([205.232.38.15]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IqHXh-0002Xs-K5; Thu, 08 Nov 2007 19:16:13 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id ABBE92AA3C4; Thu, 8 Nov 2007 19:14:15 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Ciu+FfR0Mt2Z; Thu, 8 Nov 2007 19:14:15 -0500 (EST) Received: from [127.0.0.1] (nile.gnat.com [205.232.38.5]) by rock.gnat.com (Postfix) with ESMTP id 6CE382AA145; Thu, 8 Nov 2007 19:14:15 -0500 (EST) Message-ID: <4733A637.8070004@adacore.com> Date: Fri, 09 Nov 2007 09:53:00 -0000 From: Robert Dewar User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ian Lance Taylor CC: Alexandre Oliva , Richard Guenther , gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: Designs for better debug info in GCC References: <84fc9c000711050327x74845c78ya18a3329fcf9e4d2@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-11/txt/msg00507.txt.bz2 Ian Lance Taylor wrote: > Alexandre Oliva writes: > >> So... The compiler is outputting code that tells other tools where to >> look for certain variables at run time, but it's putting incorrect >> information there. How can you possibly argue that this is not a code >> correctness issue? > > I don't see any point to going around this point again, so I'll just > note that I disagree. Well I very much agree. If you are writing certified code, then a number of evidence producing tools rely on the debugging information, and it is a problem if this information is incorrect.