This is the mail archive of the
gdb-testers@sources.redhat.com
mailing list for the GDB project.
gdb test results, gcc 3.3.2 versus gcc gcc-3_4-branch and gcc HEAD
- From: mec dot gnu at mindspring dot com (Michael Elizabeth Chastain)
- To: gcc-testresults at gcc dot gnu dot org, gdb-testers at sources dot redhat dot com
- Date: Sat, 31 Jan 2004 20:31:23 -0500 (EST)
- Subject: gdb test results, gcc 3.3.2 versus gcc gcc-3_4-branch and gcc HEAD
Here are the gdb test suite regressions from gcc 3.3.2 to gcc
gcc-3_4-branch and gcc HEAD. The dates are:
gcc HEAD 2004-01-27 09:18:37 UTC
gcc gcc-3_4-branch 2004-01-27 09:34:08 UTC
I tested on native i686-pc-linux-gnu with gdb HEAD, gdb test suite HEAD,
binutils 2.14, glibc 2.2.93-5-rh. I configured gcc with --disable-shared
and have $LANG=en_US.UTF-8. I tested gdb with "-gdwarf-2 -g2" and
"-gstabs+ -g2".
These regressions fall into four categories:
bugs in gcc 4
bugs in gdb 3
bugs in gdb test suite 1
not analyzed 1
I am going to fix the bug in the gdb test suite; then file PR's
for the bugs in gcc and gdb; then analyze the "not analyzed" some more.
Michael C
. BUGS IN GCC
. gdb.base/scope.exp: print localval, outer scope
PASS -> FAIL
# stabs+
This is a bug in gcc.
gcc leaves out one N_LBRAC/N_RBRAC pair so it generates bad
scopes. I need to file a gcc PR for this.
. gdb.java/jmisc1.exp: *
gdb.java/jmisc2.exp: *
* -> *
# dwarf-2, stabs+
This is a bug in gcc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13708
java program crashes at startup, UTF-8 environment
A java program crashes at startup if gcc is built and run in an
UTF-8 environment and the java program is linked with a static
libgcj.
. gdb.mi/mi-until.exp: until after current function
gdb.mi/mi1-until.exp: until after current function
gdb.mi/mi2-until.exp: until after current function
PASS -> FAIL
# dwarf-2, stabs+
This is another line number bug in gcc.
The source code is:
20 main ()
21 {
22 int a = 1;
23 foo ();
24 a += 2;
25 return 0;
26 }
The test is "444-exec-until until.c:25".
With gcc 3.3.2, gdb runs to line 24.
With gcc gcc-3_4-branch and gcc HEAD, gdb runs to line 23.
This is a bug in gcc.
With gcc 3.3.2 -gdwarf-2, the generated code is:
(gdb) disass main
Dump of assembler code for function main:
0x0804839e <main+0>: push %ebp
0x0804839f <main+1>: mov %esp,%ebp
0x080483a1 <main+3>: sub $0x8,%esp
0x080483a4 <main+6>: and $0xfffffff0,%esp
0x080483a7 <main+9>: mov $0x0,%eax
0x080483ac <main+14>: sub %eax,%esp
0x080483ae <main+16>: movl $0x1,0xfffffffc(%ebp)
0x080483b5 <main+23>: call 0x8048344 <foo>
0x080483ba <main+28>: lea 0xfffffffc(%ebp),%eax
0x080483bd <main+31>: addl $0x2,(%eax)
0x080483c0 <main+34>: mov $0x0,%eax
0x080483c5 <main+39>: leave
0x080483c6 <main+40>: ret
End of assembler dump.
(gdb) break 24
Breakpoint 1 at 0x80483ba: file /berman/fsf/_today_/source/gdb/HEAD/src/gdb/testsuite/gdb.mi/until.c, line 24.
With gcc gcc-3_4-branch -gdwarf-2, the generated code is:
(gdb) disass main
Dump of assembler code for function main:
0x0804838c <main+0>: push %ebp
0x0804838d <main+1>: mov %esp,%ebp
0x0804838f <main+3>: sub $0x8,%esp
0x08048392 <main+6>: and $0xfffffff0,%esp
0x08048395 <main+9>: mov $0x0,%eax
0x0804839a <main+14>: add $0xf,%eax
0x0804839d <main+17>: add $0xf,%eax
0x080483a0 <main+20>: shr $0x4,%eax
0x080483a3 <main+23>: shl $0x4,%eax
0x080483a6 <main+26>: sub %eax,%esp
0x080483a8 <main+28>: movl $0x1,0xfffffffc(%ebp)
0x080483af <main+35>: call 0x8048334 <foo>
0x080483b4 <main+40>: lea 0xfffffffc(%ebp),%eax
0x080483b7 <main+43>: addl $0x2,(%eax)
0x080483ba <main+46>: mov $0x0,%eax
0x080483bf <main+51>: leave
0x080483c0 <main+52>: ret
End of assembler dump.
(gdb) break 24
Breakpoint 1 at 0x80483b7: file /berman/fsf/_today_/source/gdb/HEAD/src/gdb/testsuite/gdb.mi/until.c, line 24.
The instructions for line 24, "a += 2", should be:
lea 0xfffffffc(%ebp), %eax
mov $0x0
With gcc gcc-3_4-branch and gcc HEAD, the "lea" instruction is no
longer part of line 24. This violates the documentation about gcc
optimization: "Statements are independent: if you stop the program
with a breakpoint between statements, you can then assign a new
value to any variable or change tbe program counter to any other
statement in the function and get exactly the results you would
expect from the source code."
I need to file a gcc PR for this.
. gdb.mi/mi-var-block.exp: create local variable foo
gdb.mi/mi-var-block.exp: delete var foo
gdb.mi/mi1-var-block.exp: create local variable foo
gdb.mi/mi1-var-block.exp: delete var foo
gdb.mi/mi2-var-block.exp: create local variable foo
gdb.mi/mi2-var-block.exp: delete var foo
PASS -> FAIL
This is a bug in gcc. This looks like the same scope bug as
gdb.base/scope.exp, "print localval outer scope".
The code is:
151 void
152 do_block_tests ()
153 {
154 int cb = 12;
155
156 {
157 int foo;
158 foo = 123;
159 {
160 int foo2;
The test script sets a breakpoint on do_block_tests and executes
to the breakpoint. With all versions of gcc -gstabs+, this is
line 154.
Then the test script executes "var-create foo * foo". This should
not create a variable because "foo" is not in scope. However,
with gcc gcc-3_4-branch and gcc HEAD, "foo" is in scope because
gcc has emitted bad LBRAC/RBRAC stabs.
. BUGS IN GDB
. gdb.base/store.exp: print old r - longest
gdb.base/store.exp: up print old r - longest
PASS -> FAIL
# dwarf-2
gdb prints:
Unhandled dwarf expression opcode 0x93
This is DW_OP_piece and gdb does not support it yet. We can
either improve gdb before the gdb 6.1 release, or we can ask gcc
to not generate DW_OP_piece in gcc 3.4.
. gdb.cp/anon-union.exp: print w *
gdb.cp/anon-union.exp: print z *
PASS -> FAIL
# dwarf-2, stabs+
This is a deficiency in gdb.
http://sources.redhat.com/gdb/bugs/1537
anonymous union at function scope, gcc 3.4
The test program says:
int main ()
{
...
union {
int z;
unsigned int w;
};
...
}
gcc improved their debug info for anonymous unions.
gdb can handle anonymous unions which are members of other
unions, but has trouble anonymous unions which are variables,
like the anonymous union which contains 'z' and 'w' above.
. gdb.cp/rtti.exp: print *obj
PASS -> FAIL
# dwarf-2
This is a bug in gdb.
http://sources.redhat.com/gdb/bugs/1511
lookup_transparent_type sometimes fails in presence of classes in namespaces
With gcc 3.3.2 -gdwarf-2:
print *obj
$3 = {<n2::Base2> = {_vptr.Base2 = 0x804e628}, <No data fields>}
With gcc gcc-3_4-branch -gdwarf-2 and gcc HEAD -gdwarf-2:
print *obj
$3 = <incomplete type>
. BUGS IN GDB TEST SUITE
. gdb.base/break.exp: run until function breakpoint, optimized file
PASS -> FAIL
# stabs+
This is a bug in the test script. The test script executes 'break
main' and runs to the breakpoint. With gcc 3.3.2, the breakpoint
falls on the first line of code. With gcc gcc-3_4-branch and gcc
HEAD, the breakpoint falls on the open brace of the function.
I need to improve the test script.
. UNKNOWN
. gdb.cp/classes.exp: print obj with enum (2)
gdb.cp/classes.exp: print obj_with_enum.priv_enum
gdb.cp/classes.exp: ptype obj_with_enum.priv_enum
gdb.cp/classes.exp: ptype obj_With_enum
PASS -> FAIL
KFAIL -> FAIL
# dwarf-2
This test script calls 'next' to get to the close brace of a
function. With gcc 3.3.2, the locals are available at this point.
With gcc gcc-3_4-branch and gcc HEAD, the locals are not available
at this point. This needs more investigation to decide whether it
is a gcc bug, a gdb bug, or a test script bug.