🚀 go-pugleaf

Consider the following test program (foo.c):

int main(int argc, char **argv)
{
  int i=0;
  if (1)
    {
      int j = 0;
      j = j + 1;
      return j;
    }
}

I have two versions of the compiler, called gcc-2.7.2 and gcc-2.6.3.
I also have gdb-4.15.  Consider the following shell session:

data:~/tmp> gcc-2.7.2 -g foo.c
data:~/tmp> gdb-4.15 a.out
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for
details.
GDB 4.15 (sparc-sun-solaris2.4), 
Copyright 1995 Free Software Foundation, Inc...
(gdb) break 7
Breakpoint 1 at 0x10670: file foo.c, line 7.
(gdb) run
Starting program: /home/magerman/tmp/a.out

Breakpoint 1, main (argc=1, argv=0xdfffe494) at foo.c:7
7	      j = j + 1;
(gdb) print j
No symbol "j" in current context.
(gdb) print i
$1 = 0
(gdb) 

With this configuration, I can't seem to view *any* variables declared
in a sub-block of a function.  This is especially painful in C++, since
I can't print value of a loop variable in a construction like:

	for (int j=0; j<10; j++) { ... }

However, the debugging session works fine under gcc-2.6.3:

data:~/tmp> gcc-2.6.3 -g foo.c
data:~/tmp> gdb-4.15 a.out
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for
details.
GDB 4.15 (sparc-sun-solaris2.4), 
Copyright 1995 Free Software Foundation, Inc...
(gdb) break 7
Breakpoint 1 at 0x10770: file foo.c, line 7.
(gdb) run
Starting program: /home/magerman/tmp/a.out

Breakpoint 1, main (argc=1, argv=0xdfffe494) at foo.c:7
7	      j = j + 1;
(gdb) print j
$1 = 0
(gdb) print i
$2 = 0
(gdb) 

I was able to determine that the significant difference is in the
generation of the stabs in the header of the assembly file output by
cc1:

data:~/tmp> gcc-2.7.2 -S -g -o foo-2.7.2.s foo.c
data:~/tmp> gcc-2.6.3 -S -g -o foo-2.6.3.s foo.c
data:~/tmp> diff foo-2.7.2.s foo-2.6.3.s
2d1
< 	.stabs	"gcc2_compiled.", 0x3c, 0, 0, 0
6a6
> 	.stabs	"gcc2_compiled.", 0x3c, 0, 0, 0
79,82c79
< 	.text
< 	.stabs "",100,0,0,.Letext
< .Letext:
< 	.ident	"GCC: (GNU) 2.7.2"
---
> 	.ident	"GCC: (GNU) 2.6.3"
data:~/tmp> head -6 foo-2.7.2.s
	.file	"foo.c"
	.stabs	"gcc2_compiled.", 0x3c, 0, 0, 0
.stabs "/home/magerman/tmp/",100,0,0,.LLtext0
.stabs "foo.c",100,0,0,.LLtext0
.section	".text"
.LLtext0:
data:~/tmp> head -6 foo-2.6.3.s
	.file	"foo.c"
.stabs "/home/magerman/tmp/",100,0,0,.LLtext0
.stabs "foo.c",100,0,0,.LLtext0
.section	".text"
.LLtext0:
	.stabs	"gcc2_compiled.", 0x3c, 0, 0, 0
data:~/tmp> 

The significant difference between the two compilers is that 2.7.2 puts
out the "gcc2_compiled" message too early.  If you move that line at
least two lines down, gdb works fine.  If I compile the assembly output
of gcc-2.6.3 with gcc-2.7.2, gdb works fine.

I traced the difference in the assembler output between 2.6.3 and 2.7.2
to the following entry in the ChangeLog:

Sat Nov  4 10:36:26 1995  Jim Wilson  <wilson@chestnut.cygnus.com>

	* sh.md (casesi_worker): Change constraint from = to +.

	* svr4.h (ASM_IDENTIFY_GCC_AFTER_SOURCE): Delete.
	(ASM_IDENTIFY_GCC): Output stab here.

If you undo the second change, the compiler and debugger seem to behave
fine.  The differences are:
data:~/gcc-2.7.2> diff config/svr4.h config/svr4.h.old
284,290c284
<   }								\
< while (0)
< 
< #define ASM_IDENTIFY_GCC_AFTER_SOURCE(FILE)			\
< do								\
<   {								\
<     if (write_symbols == DBX_DEBUG)				\
---
>     else							\
data:~/gcc-2.7.2> 

I've made this patch and rebuilt gcc-2.7.2.  I've tested it on a few
small examples, and it behaves properly.  But I'm a little reluctant to
install this patched version of the compiler until I get some
confirmation from a reliable source that this patch is reasonable.
I'm sure Jim Wilson's change was not made frivolously.  And I wonder why
I haven't seen any other complaints about this bug (I've been watching
the newsgroups as closely as possible, although it's possible I missed a
relevant post).  It makes debugging very difficult, especially in C++
where loop variables are usually scoped within the for loop.

Has anyone else experienced this behavior in gcc-2.7.2?  Can someone
running on a Solaris 2.4 system reproduce this bug?  Is my patch
acceptable, or is it going to brake other things?

Thanks in advance,
-- David Magerman
magerman@rentec.com