Re: testsuite: FAILs in funcargs.exp

Re: testsuite: FAILs in funcargs.exp

[Michael Elizabeth Chastain]

There is a long comment about this starting at line 137 of
gdb.base/condbreak.exp.

gdb prints '0xNNNNNNNN in function' when the instruction pointer
does not map to the first instruction of a line.  This is a common
issue when the function is nearly empty, like call6k or hitbottom.

It's a real bug with the gcc line number notes, but it's so harmless
to users that I would not bother to fix it.

BTW I am working on an 'empty.exp' test script to test a variety
of empty functions and their line number notes.

Michael C

Re: testsuite: FAILs in funcargs.exp

[Andrew Cagney]

> There is a long comment about this starting at line 137 of
> gdb.base/condbreak.exp.
> 
> gdb prints '0xNNNNNNNN in function' when the instruction pointer
> does not map to the first instruction of a line.  This is a common
> issue when the function is nearly empty, like call6k or hitbottom.
> 
> It's a real bug with the gcc line number notes, but it's so harmless
> to users that I would not bother to fix it.

FYI, It's harmful to users.  If the prologue isn't correctly skipped 
parameters are likely not where GDB expects them and that will lead to 
to GDB printing bogus parameter values.  As a developer I know that an 
extra 'next' gets a round the problem vis:
	(gdb) break main
	(gdb) run
	breakpoint at 0x1234 in main (argc=123455, argv=0)
	(gdb) print argc
	$1 = 123455
	(gdb) next
	(gdb) print argc
	$2 = 1
but that isn't ok for users.

 > BTW I am working on an 'empty.exp' test script to test a variety
 > of empty functions and their line number notes.

That would be useful.

Andrew

Re: testsuite: FAILs in funcargs.exp

[Corinna Vinschen]

On Tue, Sep 02, 2003 at 06:22:46PM -0400, Andrew Cagney wrote:
> >There is a long comment about this starting at line 137 of
> >gdb.base/condbreak.exp.
> >
> >gdb prints '0xNNNNNNNN in function' when the instruction pointer
> >does not map to the first instruction of a line.  This is a common
> >issue when the function is nearly empty, like call6k or hitbottom.
> >
> >It's a real bug with the gcc line number notes, but it's so harmless
> >to users that I would not bother to fix it.
> 
> FYI, It's harmful to users.  If the prologue isn't correctly skipped 
> parameters are likely not where GDB expects them and that will lead to 
> to GDB printing bogus parameter values.  As a developer I know that an 
> extra 'next' gets a round the problem vis:
> 	(gdb) break main
> 	(gdb) run
> 	breakpoint at 0x1234 in main (argc=123455, argv=0)
> 	(gdb) print argc
> 	$1 = 123455
> 	(gdb) next
> 	(gdb) print argc
> 	$2 = 1
> but that isn't ok for users.

Aren't the users developers?

Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.

Re: testsuite: FAILs in funcargs.exp

[Daniel Jacobowitz]

On Tue, Sep 02, 2003 at 03:11:13PM +0200, Corinna Vinschen wrote:
> Hi,
> 
> I have the following two FAILs when running funcargs.exp, which I don't
> quite understand:
> 
>   Breakpoint 37, 0x00001b42 in call6k () at testsuite/gdb.base/funcargs.c:360
>   360     {
>   (gdb) FAIL: gdb.base/funcargs.exp: continue to call6k
> 
> and
> 
>   Breakpoint 49, 0x00002628 in hitbottom () at testsuite/gdb.base/funcargs.c:605
>   605     {
>   (gdb) FAIL: gdb.base/funcargs.exp: run to hitbottom
> 
> As it turns out, gdb's reply contains in both cases an hex address plus the
> word "in" while in both cases expect doesn't expect this.  As a side note,
> the previous setting of these breakpoints confirms, that both breakpoints
> has been hit correctly:
> 
>   (gdb) break call6k
>   Breakpoint 37 at 0x1b42: file testsuite/gdb.base/funcargs.c, line 360.
> 
>   (gdb) break hitbottom
>   Breakpoint 49 at 0x2628: file testsuite/gdb.base/funcargs.c, line 605.
> 
> The first case fails since testsuite/lib/gdb.exp, the procedure gdb_continue
> doesn't expect a hex address:
> 
>   return [gdb_test "continue" ".*Breakpoint $decimal, $function .*" "continue to $function"];
> 
> The second case fails for the same reason in funcargs.exp, procedure
> recursive_structs_by_value:
> 
>     gdb_expect {
> 	 -re ".*Breakpoint $decimal, hitbottom .*$gdb_prompt $" { pass "run to hitbottom" }
> 	 -re "$gdb_prompt $" { fail "run to hitbottom" ; gdb_suppress_tests; }
> 	 timeout { fail "(timeout) run to hitbottom" ; gdb_suppress_tests; }
>     }
> 
> Is that a problem with these tests or why don't they expect that gdb
> prints the additional hex address?

The hex address means that GDB believes we are not at the beginning of
the line.  Normally when we skip the prologue we do end up at the
beginning of the line.

It could be a problem in prologue skipping, or it could be a problem
with the debug information; or it could just be that the tests should
be more lenient.  I don't remember if moving breakpoints to the middle
of a line in this case is considered acceptable or not.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

testsuite: FAILs in funcargs.exp

[Corinna Vinschen]

Hi,

I have the following two FAILs when running funcargs.exp, which I don't
quite understand:

  Breakpoint 37, 0x00001b42 in call6k () at testsuite/gdb.base/funcargs.c:360
  360     {
  (gdb) FAIL: gdb.base/funcargs.exp: continue to call6k

and

  Breakpoint 49, 0x00002628 in hitbottom () at testsuite/gdb.base/funcargs.c:605
  605     {
  (gdb) FAIL: gdb.base/funcargs.exp: run to hitbottom

As it turns out, gdb's reply contains in both cases an hex address plus the
word "in" while in both cases expect doesn't expect this.  As a side note,
the previous setting of these breakpoints confirms, that both breakpoints
has been hit correctly:

  (gdb) break call6k
  Breakpoint 37 at 0x1b42: file testsuite/gdb.base/funcargs.c, line 360.

  (gdb) break hitbottom
  Breakpoint 49 at 0x2628: file testsuite/gdb.base/funcargs.c, line 605.

The first case fails since testsuite/lib/gdb.exp, the procedure gdb_continue
doesn't expect a hex address:

  return [gdb_test "continue" ".*Breakpoint $decimal, $function .*" "continue to $function"];

The second case fails for the same reason in funcargs.exp, procedure
recursive_structs_by_value:

    gdb_expect {
	 -re ".*Breakpoint $decimal, hitbottom .*$gdb_prompt $" { pass "run to hitbottom" }
	 -re "$gdb_prompt $" { fail "run to hitbottom" ; gdb_suppress_tests; }
	 timeout { fail "(timeout) run to hitbottom" ; gdb_suppress_tests; }
    }

Is that a problem with these tests or why don't they expect that gdb
prints the additional hex address?

Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.