A brief analysis of the arm-elf failures for gdb

A brief analysis of the arm-elf failures for gdb

[Richard Earnshaw]

Running the gdb testsuite on an arm-elf configuration and with current gcc 
shows just 20 failures.  I've done a brief analysis of these below, it 
appears that most of the problems are related to the testsuite itself, 
rather than gdb.

FAIL: gdb.base/args.exp: correct args printed
FAIL: gdb.base/args.exp: correct args printed, one empty
FAIL: gdb.base/args.exp: correct args printed, two empty

These tests fail on a simulator because the framework omits the steps
(gdb) target sim
(gdb) load
before trying to run the program.

FAIL: gdb.base/huge.exp: print a very large data object

This loads an application over the stack space.  Consequently, when it 
runs the data area is clobbered by stack writes and we fail to get the 
desired output.  Is there an easy way to disable this test?

FAIL: gdb.base/ptype.exp: ptype t_char_array
FAIL: gdb.base/ptype.exp: ptype func_type

Neither of the above types are emitted in dwarf2 debug formats by gcc if 
they are not used.  We need some data object with that type to make this 
test useful.

FAIL: gdb.base/store.exp: next field 1
FAIL: gdb.base/store.exp: next field 2
FAIL: gdb.base/store.exp: next field 3
FAIL: gdb.base/store.exp: next field 4

The debugger is stopping on the line after the return statement (the 
closing brace for the function).  If this is a bug at all, then it is most 
likely in gcc.

FAIL: gdb.c++/anon-union.exp: print w 1
FAIL: gdb.c++/anon-union.exp: print z 1
FAIL: gdb.c++/anon-union.exp: print w 2
FAIL: gdb.c++/anon-union.exp: print z 2
FAIL: gdb.c++/anon-union.exp: print w 3
FAIL: gdb.c++/anon-union.exp: print z 3

Not sure what these are (c++).

FAIL: gdb.c++/templates.exp: ptype T5<int>
FAIL: gdb.c++/templates.exp: ptype t5i

The information appears to differ only in white space from the "new with 
unsigned int" pattern.  The pattern expects func<space>( and gdb is 
emitting func(.

FAIL: gdb.mi/mi-var-display.exp: get children local variable weird
FAIL: gdb.mi/mi1-var-display.exp: get children local variable weird

Don't know about these two.

R.

Re: A brief analysis of the arm-elf failures for gdb

[Corinna Vinschen]

On Tue, Mar 25, 2003 at 04:47:58PM +0000, Richard Earnshaw wrote:
> FAIL: gdb.base/store.exp: next field 1
> FAIL: gdb.base/store.exp: next field 2
> FAIL: gdb.base/store.exp: next field 3
> FAIL: gdb.base/store.exp: next field 4
> 
> The debugger is stopping on the line after the return statement (the 
> closing brace for the function).  If this is a bug at all, then it is most 
> likely in gcc.

AFAIK there's already a gcc patch in the loop for that.

Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen@redhat.com

Re: A brief analysis of the arm-elf failures for gdb

[Daniel Jacobowitz]

On Tue, Mar 25, 2003 at 04:47:58PM +0000, Richard Earnshaw wrote:
> Running the gdb testsuite on an arm-elf configuration and with current gcc 
> shows just 20 failures.  I've done a brief analysis of these below, it 
> appears that most of the problems are related to the testsuite itself, 
> rather than gdb.
> 
> FAIL: gdb.base/args.exp: correct args printed
> FAIL: gdb.base/args.exp: correct args printed, one empty
> FAIL: gdb.base/args.exp: correct args printed, two empty
> 
> These tests fail on a simulator because the framework omits the steps
> (gdb) target sim
> (gdb) load
> before trying to run the program.
> 
> FAIL: gdb.base/huge.exp: print a very large data object
> 
> This loads an application over the stack space.  Consequently, when it 
> runs the data area is clobbered by stack writes and we fail to get the 
> desired output.  Is there an easy way to disable this test?

Yes.  Try set_board_info <board> gdb,skip_huge_test 1.

> FAIL: gdb.base/ptype.exp: ptype t_char_array
> FAIL: gdb.base/ptype.exp: ptype func_type
> 
> Neither of the above types are emitted in dwarf2 debug formats by gcc if 
> they are not used.  We need some data object with that type to make this 
> test useful.

Definitely a test bug.

> FAIL: gdb.base/store.exp: next field 1
> FAIL: gdb.base/store.exp: next field 2
> FAIL: gdb.base/store.exp: next field 3
> FAIL: gdb.base/store.exp: next field 4
> 
> The debugger is stopping on the line after the return statement (the 
> closing brace for the function).  If this is a bug at all, then it is most 
> likely in gcc.

That's quite possible.  Should be investigated eventually.

> FAIL: gdb.c++/anon-union.exp: print w 1
> FAIL: gdb.c++/anon-union.exp: print z 1
> FAIL: gdb.c++/anon-union.exp: print w 2
> FAIL: gdb.c++/anon-union.exp: print z 2
> FAIL: gdb.c++/anon-union.exp: print w 3
> FAIL: gdb.c++/anon-union.exp: print z 3
> 
> Not sure what these are (c++).

Don't know.  Until a few weeks ago when Jason fixed it, GCC couldn't
even compile this test.

> 
> FAIL: gdb.c++/templates.exp: ptype T5<int>
> FAIL: gdb.c++/templates.exp: ptype t5i
> 
> The information appears to differ only in white space from the "new with 
> unsigned int" pattern.  The pattern expects func<space>( and gdb is 
> emitting func(.

I think David Carlton had a patch for this?

> FAIL: gdb.mi/mi-var-display.exp: get children local variable weird
> FAIL: gdb.mi/mi1-var-display.exp: get children local variable weird
> 
> Don't know about these two.

These fail everywhere with GCC 3.x, someone should look into it.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: A brief analysis of the arm-elf failures for gdb

[Michael Elizabeth Chastain]

re> FAIL: gdb.base/ptype.exp: ptype t_char_array
re> FAIL: gdb.base/ptype.exp: ptype func_type
re> 
re> Neither of the above types are emitted in dwarf2 debug formats by gcc if 
re> they are not used.  We need some data object with that type to make this 
re> test useful.

I saw these as regressions with gcc HEAD.  They PASSed with
gcc HEAD on 2003-02-27 and FAILed with gcc HEAD on 2003-03-15.
The tests PASSed with gcc 2.95.3, gcc 3.2.2, gcc gcc-3_2-branch,
and gcc gcc-3_3-branch.

drow> Definitely a test bug.

That's good news.  So it looks like gcc HEAD has gotten sharper about
generating type definitions, exposing a latent problem in the test.

Michael C