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

[Daniel Jacobowitz <drow at mvista dot com>]

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