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
next prev parent 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).