From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-143062-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 24979 invoked by alias); 18 Dec 2007 01:24:48 -0000
Received: (qmail 24959 invoked by uid 22791); 18 Dec 2007 01:24:47 -0000
X-Spam-Check-By: sourceware.org
Received: from us02smtp1.synopsys.com (HELO vaxjo.synopsys.com) (198.182.60.75)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 18 Dec 2007 01:24:41 +0000
Received: from maiden.synopsys.com (maiden.synopsys.com [146.225.100.170]) 	by vaxjo.synopsys.com (Postfix) with ESMTP id 31578DD0E; 	Mon, 17 Dec 2007 17:24:39 -0800 (PST)
Received: from piper.synopsys.com (localhost [127.0.0.1]) 	by maiden.synopsys.com (8.9.1/8.9.1) with ESMTP id RAA27833; 	Mon, 17 Dec 2007 17:24:38 -0800 (PST)
Received: from piper.synopsys.com (localhost [127.0.0.1]) 	by piper.synopsys.com (8.12.11/8.12.3) with ESMTP id lBI1OcqG007450; 	Mon, 17 Dec 2007 17:24:38 -0800
Received: (from jbuck@localhost) 	by piper.synopsys.com (8.12.11/8.12.11/Submit) id lBI1OcYW007448; 	Mon, 17 Dec 2007 17:24:38 -0800
Date: Tue, 18 Dec 2007 02:02:00 -0000
From: Joe Buck <Joe.Buck@synopsys.COM>
To: Alexandre Oliva <aoliva@redhat.com>
Cc: Geert Bosch <bosch@adacore.com>, Daniel Berlin <dberlin@dberlin.org>,         Diego Novillo <dnovillo@google.com>,         Mark Mitchell <mark@codesourcery.com>,         Robert Dewar <dewar@adacore.com>, Ian Lance Taylor <iant@google.com>,         Richard Guenther <richard.guenther@gmail.com>, gcc-patches@gcc.gnu.org,         gcc@gcc.gnu.org
Subject: Re: Designs for better debug info in GCC
Message-ID: <20071218012438.GD2908@synopsys.com>
References: <ory7cok8u6.fsf@oliva.athome.lsd.ic.unicamp.br> <4749DE66.1090602@codesourcery.com> <4756B02D.9010302@google.com> <ory7bv3adb.fsf@oliva.athome.lsd.ic.unicamp.br> <4aca3dc20712151903r46c9eceane35edb92d08240ac@mail.gmail.com> <oraboaero7.fsf@oliva.athome.lsd.ic.unicamp.br> <4aca3dc20712161712w1133fb96qd66be0e9a0bb1716@mail.gmail.com> <20071217012735.GA9275@synopsys.com> <8DF14649-456C-40D6-94C5-DC3285EFD7C2@adacore.com> <orabo8zu0d.fsf@oliva.athome.lsd.ic.unicamp.br>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <orabo8zu0d.fsf@oliva.athome.lsd.ic.unicamp.br>
User-Agent: Mutt/1.4.1i
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
X-SW-Source: 2007-12/txt/msg00502.txt.bz2

On Mon, Dec 17, 2007 at 11:11:46PM -0200, Alexandre Oliva wrote:
> Line number information has a well-defined meaning: it ought to
> represent the source code line that best represents the source-code
> construct that ended up implemented using that instruction.

You implicitly assume that souch a source code line exists.
Consider something like

int func(bool cond, int a, int b, int c)
{
  int out;
  if (cond)
    out = a + b;
  else
    out = a + b + c;
  return out;
}

The optimizer might produce something that structurally resembles

  out = a + b;
  if (!cond)
    out += c;
  return out;

If you set a breakpoint on the addition of a and b, it will trigger
regardless of the value of cond.  Furthermore, there isn't a place
to put a breakpoint that will trigger only for the case where cond
is true, as you can on unoptimized code.  So you need to choose
between natural debugging and optimization.