From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21930 invoked by alias); 4 Dec 2001 21:08:12 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 21869 invoked from network); 4 Dec 2001 21:08:11 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 4 Dec 2001 21:08:11 -0000 Received: from drow by nevyn.them.org with local (Exim 3.33 #1 (Debian)) id 16BMo1-0004Px-00; Tue, 04 Dec 2001 16:08:45 -0500 Date: Tue, 04 Dec 2001 13:08:00 -0000 From: Daniel Jacobowitz To: Neil Booth Cc: gcc-gnats@gcc.gnu.org, mike stump , danishsamad@yahoo.com, gcc@gcc.gnu.org Subject: [c/4053] Re: problems debugging gcc Message-ID: <20011204160845.A15532@nevyn.them.org> Mail-Followup-To: Neil Booth , gcc-gnats@gcc.gnu.org, mike stump , danishsamad@yahoo.com, gcc@gcc.gnu.org References: <200112041958.LAA06265@kankakee.wrs.com> <20011204203454.A20475@daikokuya.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011204203454.A20475@daikokuya.demon.co.uk> User-Agent: Mutt/1.3.23i X-SW-Source: 2001-12/txt/msg00166.txt.bz2 On Tue, Dec 04, 2001 at 08:34:54PM +0000, Neil Booth wrote: > mike stump wrote:- > > > Yes. Step through bison.simple a couple hundred times, and you'll > > discover that most of the time, it spends it's time in about two to > > four places you care about. One place, is dispatching to actions. It > > can be felt, by noticing the line (at least in bison 1.25): > > Have you noticed that you often get the debugger trying to step to a > line in bison.simple that is in fact in parse.y, and complaining about > a line out range? For the curious, this is the exact same problem as c/4053. > This happens to me very frequently; I have no idea what causes it. I > have a sneaking suspicion that this GCC bug is what the original post > was about, though I'm not sure. Well, it isn't in the debug format code; the file information in the RTL is wrong. And there's nothing obviously incorrect about the code in cb_file_change... Aha, I think I see it. cb_file_change updates input_filename as it reads. Compile the testcase from the PR with a breakpoint on cb_file_change and a breakpoint on emit_line_note. If I had to guess, I'd say that the problem was input_filename describing the state of the lexer where it used to describe the state of the parser. In c_expand_body is the line: init_function_start (fndecl, input_filename, DECL_SOURCE_LINE (fndecl)); DECL_SOURCE_LINE is fine. input_filename isn't. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer