Re: problems debugging gcc

Re: problems debugging gcc

[mike stump]

> 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.

Re: problems debugging gcc

[Neil Booth]

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.

[c/4053] Re: problems debugging gcc

[Daniel Jacobowitz]

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

Re: [c/4053] Re: problems debugging gcc

[Neil Booth]

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.

Re: problems debugging gcc

[Geoff Keating]

Neil Booth <neil@daikokuya.demon.co.uk> writes:

> 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.

There's a bug in cc1: it doesn't store file names for statements, only
line numbers, and so debugging information for functions that have
lines from multiple files is often wrong.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Re: problems debugging gcc

[Neil Booth]

Geoff Keating wrote:-

> There's a bug in cc1: it doesn't store file names for statements, only
> line numbers, and so debugging information for functions that have
> lines from multiple files is often wrong.

Hmm, sounds like it's non-trivial to fix and been around forever then.

It also sounds like a good reason to use the line maps and drop the
mucking about with global filename and line number variables, no?

Neil.

Re: problems debugging gcc

[Geoff Keating]

> Date: Tue, 4 Dec 2001 22:32:13 +0000
> From: Neil Booth <neil@daikokuya.demon.co.uk>
> Cc: gcc@gcc.gnu.org
> Content-Disposition: inline
> User-Agent: Mutt/1.3.23i
> 
> Geoff Keating wrote:-
> 
> > There's a bug in cc1: it doesn't store file names for statements, only
> > line numbers, and so debugging information for functions that have
> > lines from multiple files is often wrong.
> 
> Hmm, sounds like it's non-trivial to fix and been around forever then.
> 
> It also sounds like a good reason to use the line maps and drop the
> mucking about with global filename and line number variables, no?

Oh, it's not related to the global variables.  If it was just that,
I'd have fixed it a month ago.  Look at STMT_LINENO in c-common.h, and
notice there is no STMT_FILENAME nor any easy way to add one.

It started around when functions-as-trees was added.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Re: problems debugging gcc

[Neil Booth]

Geoff Keating wrote:-

> Oh, it's not related to the global variables.  If it was just that,
> I'd have fixed it a month ago.  Look at STMT_LINENO in c-common.h, and
> notice there is no STMT_FILENAME nor any easy way to add one.
> 
> It started around when functions-as-trees was added.

Instead of adding a filename component and taking up more memory,
would it be too much to switch to using a single lineno and using the
line maps to imply the file name?  It probably is for a quick patch,
but I might as well try.  If it is too much, do you nevertheless agree
that this, and similarly in other places, is worthwhile doing in GCC?

Neil.

Re: problems debugging gcc

[Richard Henderson]

On Tue, Dec 04, 2001 at 11:38:07PM +0000, Neil Booth wrote:
> Instead of adding a filename component and taking up more memory,
> would it be too much to switch to using a single lineno and using the
> line maps to imply the file name?

This seems like a fine idea.


r~

Re: [c/4053] Re: problems debugging gcc

[mike stump]

> 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;
--------------

Re: [c/4053] Re: problems debugging gcc

[Neil Booth]

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.