From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3107 invoked by alias); 23 Nov 2007 15:49:21 -0000 Received: (qmail 3090 invoked by uid 22791); 23 Nov 2007 15:49:20 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 23 Nov 2007 15:49:14 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.1) with ESMTP id lANFlBbR013827; Fri, 23 Nov 2007 10:47:11 -0500 Received: from pobox-3.corp.redhat.com (pobox-3.corp.redhat.com [10.11.255.67]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id lANFlA2r030794; Fri, 23 Nov 2007 10:47:10 -0500 Received: from touchme.toronto.redhat.com (IDENT:postfix@touchme.yyz.redhat.com [10.15.16.9]) by pobox-3.corp.redhat.com (8.13.1/8.13.1) with ESMTP id lANFkDv2028298; Fri, 23 Nov 2007 10:46:45 -0500 Received: from ton.toronto.redhat.com (ton.yyz.redhat.com [10.15.16.15]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 1F4B68001FF; Fri, 23 Nov 2007 10:45:57 -0500 (EST) Received: from ton.toronto.redhat.com (localhost.localdomain [127.0.0.1]) by ton.toronto.redhat.com (8.13.1/8.13.1) with ESMTP id lANFjexi014077; Fri, 23 Nov 2007 10:45:40 -0500 Received: (from fche@localhost) by ton.toronto.redhat.com (8.13.1/8.13.1/Submit) id lANFjdAT014076; Fri, 23 Nov 2007 10:45:39 -0500 Date: Fri, 23 Nov 2007 23:40:00 -0000 From: "Frank Ch. Eigler" To: Richard Guenther Cc: Mark Mitchell , David Edelsohn , Ian Lance Taylor , Alexandre Oliva , gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: Designs for better debug info in GCC Message-ID: <20071123154539.GA3908@redhat.com> References: <84fc9c000711050327x74845c78ya18a3329fcf9e4d2@mail.gmail.com> <4732519C.6070802@codesourcery.com> <200711080014.lA80EEiA028452@makai.watson.ibm.com> <473259AA.1070400@codesourcery.com> <84fc9c000711221140o3e32ec65i913ce2fd60666588@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84fc9c000711221140o3e32ec65i913ce2fd60666588@mail.gmail.com> User-Agent: Mutt/1.4.1i Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2007-11/txt/msg00587.txt.bz2 Hi - (BTW, sorry for reopening this old thread if people are sick & tired of it.) > > Mark Mitchell writes: > > > [...] > > > That's what I'm asking. First and foremost, I want to know what, > > > concretely, Alexandre is trying to achieve, beyond "better debugging > > > info for optimized code". [...] > > > > It may be asking to belabour the obvious. GCC users do not want to > > have to compile with "-O0 -g" just to debug during development [...] > > Developers will accept that optimized code will by its nature make > > some of these fuzzy, but incorrect data must be and incomplete data > > should be minimized. [...] > > As it is (without serious overhead) impossible to do both, you either have > to live with possibly incorrect but elaborate or incomplete but correct > debug information for optimized code. Choose one ;) I did say "minimized", not "eliminated". It needs to be good enough that a semi-knowledgable person or a dumb but heuristic-laden program that processes debugging info can nevertheless extract reliable information. > What we (Matz and myself) are trying to do is provide elaborate > debug information with the chance of wrong (I'd call it superflous, > or extra) debug information. (I will need to reread the thread to see what this extra information can do in terms of misleading users or tools, such as giving incorrect variable values/locations. I'd appreciate a link if you have one handy.) > Alexandre seems to aim at the world-domination solution (with the > serious overhead in terms of implementation and verboseness). That ("world-domination") seems an overly unkind characterization - we could simply say he's trying an exhaustive, straining-to-be-correct solution. It seems to me that we will shortly see the actual impacts of both of these approaches in terms of compiler complexity as well as any improvements in data quality. It does not seem to me like there is substantial disagreement over the ideal of correct and to a lesser extent complete information, so let's see the implementations and then compare. - FChE