* Re: [c/4053] Re: problems debugging gcc
@ 2001-12-04 17:03 mike stump
2001-12-05 15:10 ` Neil Booth
2001-12-05 15:17 ` c/4053 " Daniel Jacobowitz
0 siblings, 2 replies; 5+ messages in thread
From: mike stump @ 2001-12-04 17:03 UTC (permalink / raw)
To: drow, neil; +Cc: danishsamad, gcc-gnats, gcc
> Date: Tue, 4 Dec 2001 16:08:45 -0500
> From: Daniel Jacobowitz <drow@mvista.com>
> To: Neil Booth <neil@daikokuya.demon.co.uk>
> 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.
Ok, since you did all the hard work, test out the below, and let us
know if it works. Could someone else run a dejagnu run on it, then we
can submit it for inclusion.
2001-12-04 Mike Stump <mrs@wrs.com>
* c-decl.c (c_expand_body): Use the name of the file associated
with the fndecl, not the current input filename.
*** c-decl.c.~1~ Tue Dec 4 16:52:33 2001
--- c-decl.c Tue Dec 4 16:54:14 2001
*************** c_expand_body (fndecl, nested_p, can_def
*** 6889,6895 ****
/* Initialize the RTL code for the function. */
current_function_decl = fndecl;
! init_function_start (fndecl, input_filename, DECL_SOURCE_LINE (fndecl));
/* This function is being processed in whole-function mode. */
cfun->x_whole_function_mode_p = 1;
--- 6889,6897 ----
/* Initialize the RTL code for the function. */
current_function_decl = fndecl;
! init_function_start (fndecl,
! DECL_SOURCE_FILE (fndecl),
! DECL_SOURCE_LINE (fndecl));
/* This function is being processed in whole-function mode. */
cfun->x_whole_function_mode_p = 1;
--------------
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [c/4053] Re: problems debugging gcc
2001-12-04 17:03 [c/4053] Re: problems debugging gcc mike stump
@ 2001-12-05 15:10 ` Neil Booth
2001-12-05 15:17 ` c/4053 " Daniel Jacobowitz
1 sibling, 0 replies; 5+ messages in thread
From: Neil Booth @ 2001-12-05 15:10 UTC (permalink / raw)
To: mike stump; +Cc: drow, danishsamad, gcc-gnats, gcc
mike stump wrote:-
> Ok, since you did all the hard work, test out the below, and let us
> know if it works. Could someone else run a dejagnu run on it, then we
> can submit it for inclusion.
Sorry, it didn't change anything for me.
Neil.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: c/4053 Re: problems debugging gcc
2001-12-04 17:03 [c/4053] Re: problems debugging gcc mike stump
2001-12-05 15:10 ` Neil Booth
@ 2001-12-05 15:17 ` Daniel Jacobowitz
1 sibling, 0 replies; 5+ messages in thread
From: Daniel Jacobowitz @ 2001-12-05 15:17 UTC (permalink / raw)
To: mike stump; +Cc: neil, danishsamad, gcc-gnats, gcc
On Tue, Dec 04, 2001 at 05:02:14PM -0800, mike stump wrote:
> > Date: Tue, 4 Dec 2001 16:08:45 -0500
> > From: Daniel Jacobowitz <drow@mvista.com>
> > To: Neil Booth <neil@daikokuya.demon.co.uk>
>
> > 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.
>
> Ok, since you did all the hard work, test out the below, and let us
> know if it works. Could someone else run a dejagnu run on it, then we
> can submit it for inclusion.
>
> 2001-12-04 Mike Stump <mrs@wrs.com>
>
> * c-decl.c (c_expand_body): Use the name of the file associated
> with the fndecl, not the current input filename.
>
> *** c-decl.c.~1~ Tue Dec 4 16:52:33 2001
> --- c-decl.c Tue Dec 4 16:54:14 2001
> *************** c_expand_body (fndecl, nested_p, can_def
> *** 6889,6895 ****
>
> /* Initialize the RTL code for the function. */
> current_function_decl = fndecl;
> ! init_function_start (fndecl, input_filename, DECL_SOURCE_LINE (fndecl));
>
> /* This function is being processed in whole-function mode. */
> cfun->x_whole_function_mode_p = 1;
> --- 6889,6897 ----
>
> /* Initialize the RTL code for the function. */
> current_function_decl = fndecl;
> ! init_function_start (fndecl,
> ! DECL_SOURCE_FILE (fndecl),
> ! DECL_SOURCE_LINE (fndecl));
>
> /* This function is being processed in whole-function mode. */
> cfun->x_whole_function_mode_p = 1;
> --------------
I don't expect this to have any effect, and Neil seemed to confirm
that. Every reference to the input_filename global in the front-end is
going to be similarly wrong. See all of c-semantics, for instance.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: problems debugging gcc
@ 2001-12-04 11:59 mike stump
2001-12-04 12:34 ` Neil Booth
0 siblings, 1 reply; 5+ messages in thread
From: mike stump @ 2001-12-04 11:59 UTC (permalink / raw)
To: danishsamad, gcc
> Date: Tue, 4 Dec 2001 01:21:29 -0800 (PST)
> From: Danish Samad <danishsamad@yahoo.com>
> To: gcc@gcc.gnu.org
> I am facing some problems debugging gcc. Whenever I try to step into
> the function yyparse(), in the toplevel.c file, it steps into
> bison.simple instead of c-parse.c. Although there is a portion in
> bison.simple which says that the action file gets copied here but
> while debugging this portion it says file out of range. Any
> solution to this problem?
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):
switch (yyn) {
and the fact that when you step it, it will be at a line in your
parse.y file. If you set a break point on that line, with the command
step 1, you will discover that you always wind up stopped inside an
action, and that you always stop for all actions. This is very handy.
The next thing that is handy, is to have compiled with -DYYDEBUG=1 and
set yydebug to 1, and then set a break point on the lines like (again,
these are from bison 1.25, your mileage may vary):
#if YYDEBUG != 0
if (yydebug)
fprintf(stderr, "Entering state %d\n", yystate);
#endif
#if YYDEBUG != 0
if (yydebug)
fprintf(stderr, "Shifting token %d (%s), ", yychar, yytname[yychar1]);
#endif
fprintf (stderr, "Reducing via rule %d (line %d), ",
yyn, yyrline[yyn]);
depending upon what you want to see. Feel free to contribute this to
the bison manual, if it helps you. About the out of range stuff, best
to just ignore it, step until you get someplace you want to be.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: problems debugging gcc
2001-12-04 11:59 mike stump
@ 2001-12-04 12:34 ` Neil Booth
2001-12-04 13:08 ` [c/4053] " Daniel Jacobowitz
0 siblings, 1 reply; 5+ messages in thread
From: Neil Booth @ 2001-12-04 12:34 UTC (permalink / raw)
To: mike stump; +Cc: danishsamad, gcc
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?
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.
Neil.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [c/4053] Re: problems debugging gcc
2001-12-04 12:34 ` Neil Booth
@ 2001-12-04 13:08 ` Daniel Jacobowitz
2001-12-04 13:18 ` Neil Booth
0 siblings, 1 reply; 5+ messages in thread
From: Daniel Jacobowitz @ 2001-12-04 13:08 UTC (permalink / raw)
To: Neil Booth; +Cc: gcc-gnats, mike stump, danishsamad, gcc
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [c/4053] Re: problems debugging gcc
2001-12-04 13:08 ` [c/4053] " Daniel Jacobowitz
@ 2001-12-04 13:18 ` Neil Booth
0 siblings, 0 replies; 5+ messages in thread
From: Neil Booth @ 2001-12-04 13:18 UTC (permalink / raw)
To: gcc-gnats, mike stump, danishsamad, gcc
Daniel Jacobowitz wrote:-
> 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.
Cool! This looks like it. I'll take a closer look and post a patch
if it works.
Thanks a lot for the detective work!
Neil.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2001-12-05 23:17 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-12-04 17:03 [c/4053] Re: problems debugging gcc mike stump
2001-12-05 15:10 ` Neil Booth
2001-12-05 15:17 ` c/4053 " Daniel Jacobowitz
-- strict thread matches above, loose matches on Subject: below --
2001-12-04 11:59 mike stump
2001-12-04 12:34 ` Neil Booth
2001-12-04 13:08 ` [c/4053] " Daniel Jacobowitz
2001-12-04 13:18 ` Neil Booth
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).