Strange debug behavior with 4.4.3

Strange debug behavior with 4.4.3

[Steve Teale]

I just built 4.4.3 - very simply

mkdir obdir
cd objdir
../configure --enable-languages=c,c++
make

make finished without errors, so then with a file foo.c

void foo()
{
}

I debug

steve@Ubuntu:~/gcc-4.4.3/objdir$ gdb --args gcc/cc1 ~/scratch/foo.c
GNU gdb (GDB) 7.0-ubuntu
...
This GDB was configured as "i486-linux-gnu".
...
Reading symbols from /home/steve/gcc-4.4.3/objdir/gcc/cc1...done.
(gdb) b gimplify.c:6249
Breakpoint 1 at 0x81a520c: file ../../gcc/gimplify.c, line 6249.
(gdb) run
Starting
program: /home/steve/gcc-4.4.3/objdir/gcc/cc1 /home/steve/scratch/foo.c
 foo
Breakpoint 1, gimplify_expr (expr_p=0xb7f41758, pre_p=0xbffff1b8,
post_p=0x0, 
    gimple_test_f=0x819b000 <is_gimple_stmt>, fallback=fb_none)
    at ../../gcc/gimplify.c:6249
6249	  save_expr = *expr_p;
(gdb) n
6250	  if (save_expr == NULL_TREE)
(gdb) n
6254	  is_statement = gimple_test_f == is_gimple_stmt;
(gdb) n
6255	  if (is_statement)
(gdb) n
6256	    gcc_assert (pre_p);
(gdb) n
6259	  if (gimple_test_f == is_gimple_reg)
(gdb) n
6261	  else if (gimple_test_f == is_gimple_val
(gdb) n
6274	  else if (gimple_test_f == is_gimple_min_lval
(gdb) n
6277	  else if (gimple_test_f == is_gimple_addressable)
(gdb) n
6279	  else if (gimple_test_f == is_gimple_stmt)
(gdb) n
6280	    gcc_assert (fallback == fb_none);
(gdb) n
6293	  if (pre_p == NULL)
(gdb) n
6296	  if (post_p == NULL)
(gdb) n
6307	  pre_last_gsi = gsi_last (*pre_p);
(gdb) n
6308	  post_last_gsi = gsi_last (*post_p);
(gdb) n
6310	  saved_location = input_location;
(gdb) n
6311	  if (save_expr != error_mark_node
(gdb) n
6312	      && EXPR_HAS_LOCATION (*expr_p))
(gdb) n
6311	  if (save_expr != error_mark_node
(gdb) n
6313	    input_location = EXPR_LOCATION (*expr_p);
(gdb) n
6729				   post_p == &internal_post ? NULL : post_p,

Things go pear shaped after line 6312 - after that, next seems to get
you somewhere rather arbitrary.

I guess I'm doing something stupid - can anyone tell me what?

Thanks
Steve

Re: Strange debug behavior with 4.4.3

[Ian Lance Taylor]

Steve Teale <steve.teale@britseyeview.com> writes:

> (gdb) n
> 6313	    input_location = EXPR_LOCATION (*expr_p);
> (gdb) n
> 6729				   post_p == &internal_post ? NULL : post_p,
>
> Things go pear shaped after line 6312 - after that, next seems to get
> you somewhere rather arbitrary.

You are debugging optimized code.  Random jumps do happen.  You need
to go further to see if there is a real problem here.

Ian

Re: Strange debug behavior with 4.4.3

[Steve Teale]

On Wed, 2010-03-03 at 07:40 -0800, Ian Lance Taylor wrote:
> Steve Teale <steve.teale@britseyeview.com> writes:
> 
> > (gdb) n
> > 6313	    input_location = EXPR_LOCATION (*expr_p);
> > (gdb) n
> > 6729				   post_p == &internal_post ? NULL : post_p,
> >
> > Things go pear shaped after line 6312 - after that, next seems to get
> > you somewhere rather arbitrary.
> 
> You are debugging optimized code.  Random jumps do happen.  You need
> to go further to see if there is a real problem here.
> 
> Ian

Ian,

Go further?

So should I build the compiler with no optimization?

My problem is that I am trying to build the GDC compiler for 4.4.3. This
(for historical reasons I don't want to get involved in) involves
actually patching some GCC code. However the changes in 4.4.3 are such
that are such that applying the existing (4.3.4) patches is not at all
obvious.

To investigate what needs to be done I could really use the debugger,
but of course since I patched the code I don't know if it is generating
proper debug info. Catch 22.

Any suggestions?

Thanks
Steve

Re: Strange debug behavior with 4.4.3

[Ian Lance Taylor]

Steve Teale <steve.teale@britseyeview.com> writes:

> On Wed, 2010-03-03 at 07:40 -0800, Ian Lance Taylor wrote:
>> Steve Teale <steve.teale@britseyeview.com> writes:
>> 
>> > (gdb) n
>> > 6313	    input_location = EXPR_LOCATION (*expr_p);
>> > (gdb) n
>> > 6729				   post_p == &internal_post ? NULL : post_p,
>> >
>> > Things go pear shaped after line 6312 - after that, next seems to get
>> > you somewhere rather arbitrary.
>> 
>> You are debugging optimized code.  Random jumps do happen.  You need
>> to go further to see if there is a real problem here.
>> 
>> Ian
>
> Ian,
>
> Go further?

I mean: run the "n" command a few more times to see where you get to.

> So should I build the compiler with no optimization?

That is probably a good idea if you want to debug the compiler.

Ian

Re: Strange debug behavior with 4.4.3

[Steve Teale]

Ian,

I rebuilt with -g -O, and to be fair it is slightly better. Now it just
repeats line sequences it has done before, and does present an overall.
sequence you can decipher if you have a rough idea what's coming.

Looks to me like the sequence AST -> Generic -> Gimple is already
chopping stuff out with no, or an incorrect, corresponding adjustment to
the debug info and that this can't be classified as optimization.
because it is just how the middle-tier works.

I see similar behavior with 4.3.4, so it's not something that just
happened.

I don't see how you could use it if you were looking at a genuine bug,
and did not really know what to expect.

Steve

On Wed, 2010-03-03 at 08:08 -0800, Ian Lance Taylor wrote:
> Steve Teale <steve.teale@britseyeview.com> writes:
> 
> > On Wed, 2010-03-03 at 07:40 -0800, Ian Lance Taylor wrote:
> >> Steve Teale <steve.teale@britseyeview.com> writes:
> >> 
> >> > (gdb) n
> >> > 6313	    input_location = EXPR_LOCATION (*expr_p);
> >> > (gdb) n
> >> > 6729				   post_p == &internal_post ? NULL : post_p,
> >> >
> >> > Things go pear shaped after line 6312 - after that, next seems to get
> >> > you somewhere rather arbitrary.
> >> 
> >> You are debugging optimized code.  Random jumps do happen.  You need
> >> to go further to see if there is a real problem here.
> >> 
> >> Ian
> >
> > Ian,
> >
> > Go further?
> 
> I mean: run the "n" command a few more times to see where you get to.
> 
> > So should I build the compiler with no optimization?
> 
> That is probably a good idea if you want to debug the compiler.
> 
> Ian

Re: Strange debug behavior with 4.4.3

[Ian Lance Taylor]

Steve Teale <steve.teale@britseyeview.com> writes:

> Looks to me like the sequence AST -> Generic -> Gimple is already
> chopping stuff out with no, or an incorrect, corresponding adjustment to
> the debug info and that this can't be classified as optimization.
> because it is just how the middle-tier works.
>
> I see similar behavior with 4.3.4, so it's not something that just
> happened.
>
> I don't see how you could use it if you were looking at a genuine bug,
> and did not really know what to expect.

There is active and ongoing work to improve the debug info generation
when optimizing.  Specific test cases with detailed bug reports can
certainly help.

Generally the debug info is not changed incorrectly.  One case where
the line number appears random is that some code from different lines
is identical and has been gathered together, but only one line number
is displayed, and it is not the one you expect.

Ian