public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: Neil Booth <neil@daikokuya.demon.co.uk>
Cc: gcc-gnats@gcc.gnu.org, mike stump <mrs@windriver.com>,
	danishsamad@yahoo.com, gcc@gcc.gnu.org
Subject: [c/4053] Re: problems debugging gcc
Date: Tue, 04 Dec 2001 13:08:00 -0000	[thread overview]
Message-ID: <20011204160845.A15532@nevyn.them.org> (raw)
In-Reply-To: <20011204203454.A20475@daikokuya.demon.co.uk>

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

  reply	other threads:[~2001-12-04 21:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-04 11:59 mike stump
2001-12-04 12:34 ` Neil Booth
2001-12-04 13:08   ` Daniel Jacobowitz [this message]
2001-12-04 13:18     ` [c/4053] " Neil Booth
2001-12-04 14:24   ` Geoff Keating
2001-12-04 14:31     ` Neil Booth
2001-12-04 15:27       ` Geoff Keating
2001-12-04 15:37         ` Neil Booth
2001-12-05 15:43           ` Richard Henderson
2001-12-04 17:03 [c/4053] " mike stump
2001-12-05 15:10 ` Neil Booth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20011204160845.A15532@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=danishsamad@yahoo.com \
    --cc=gcc-gnats@gcc.gnu.org \
    --cc=gcc@gcc.gnu.org \
    --cc=mrs@windriver.com \
    --cc=neil@daikokuya.demon.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).