[patch/rfa] tweak patterns for annota3.exp

[patch/rfa] tweak patterns for annota3.exp

[Randolph Chung]

Note: i don't really understand the annotation stuff in gdb...

I've been getting FAILs for this test for a long time, and i never quite
understood why....

In the first case, i see an extra \r\n between "breakpoint 2" and
"Breakpoint 2, ...". Also on hppa-linux, the backtrace prints out the
address of the signal handler... i.e. i get 

#0  0x000105d4 in handle_USR1 (sig=16) at /home/tausq/gdb/gdb-cvs/gdb/testsuite/gdb.base/annota3.c:18

instead of what the script expected, which seems to be
#0  handle_USR1 (sig=16) at /home/tausq/gdb/gdb-cvs/gdb/testsuite/gdb.base/annota3.c:18

i see from test results posted by others that these tests do pass on
other platforms, but i don't see how this could be hppa specific....

can someone enlighten me about what's going on? or is this patch ok?

randolph


2004-12-05  Randolph Chung  <tausq@debian.org>

	* gdb.base/annota3.exp: allow addresses to be printed for signal 
	handlers, and multiple \r\n sequences after "breakpoint n".

Index: testsuite/gdb.base/annota3.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/annota3.exp,v
retrieving revision 1.5
diff -u -p -r1.5 annota3.exp
--- testsuite/gdb.base/annota3.exp	20 Jul 2004 00:24:41 -0000	1.5
+++ testsuite/gdb.base/annota3.exp	6 Dec 2004 02:13:54 -0000
@@ -228,8 +228,8 @@ if [target_info exists gdb,nosignals] {
 	"Continuing with signal SIGUSR1.\r\n"
 	"\r\n\032\032starting\r\n"
 	"\r\n\032\032frames-invalid\r\n"
-	"\r\n\032\032breakpoint 2\r\n"
-	"Breakpoint 2, handle_USR1 \\(sig=\[0-9\]+\\) at .*annota3.c:\[0-9\]+\r\n"
+	"\r\n\032\032breakpoint 2\[\r\n\]+"
+	"Breakpoint 2, .*handle_USR1 \\(sig=\[0-9\]+\\) at .*annota3.c:\[0-9\]+\r\n"
 	"\r\n\032\032source .*annota3.c:\[0-9\]+:\[0-9\]+:beg:0x\[0-9a-z\]+\r\n"
 	"\r\n\032\032stopped\r\n"
     }
@@ -245,7 +245,7 @@ if [target_info exists gdb,nosignals] {
     verbose "match_max now is: [match_max]"
     send_gdb "backtrace\n"
     gdb_expect_list "backtrace @ signal handler" "$gdb_prompt$" {
-	"#0 +handle_USR1 \[^\r\n\]+\r\n"
+	"#0 .*handle_USR1 \[^\r\n\]+\r\n"
 	"#1 +.signal handler called.\r\n"
 	"#2 .* printf \[^\r\n\]+\r\n"
 	"#3 .* main \[^\r\n\]+\r\n"
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [patch/rfa] tweak patterns for annota3.exp

[Daniel Jacobowitz]

On Sun, Dec 05, 2004 at 06:19:44PM -0800, Randolph Chung wrote:
> Note: i don't really understand the annotation stuff in gdb...
> 
> I've been getting FAILs for this test for a long time, and i never quite
> understood why....
> 
> In the first case, i see an extra \r\n between "breakpoint 2" and
> "Breakpoint 2, ...". Also on hppa-linux, the backtrace prints out the

Are you sure there's nothing but an extra \r\n?  It definitely passes
for others, so I'd like to know where that came from.

> address of the signal handler... i.e. i get 
> 
> #0  0x000105d4 in handle_USR1 (sig=16) at /home/tausq/gdb/gdb-cvs/gdb/testsuite/gdb.base/annota3.c:18
> 
> instead of what the script expected, which seems to be
> #0  handle_USR1 (sig=16) at /home/tausq/gdb/gdb-cvs/gdb/testsuite/gdb.base/annota3.c:18

The extra address means we didn't put the breakpoint at the beginning
of a line.  This could be a prologue skipper bug, a GCC bug, a general
the-world-hates-us bug, or we could decide it wasn't a bug.  The
testsuite seems to contain examples of all of the above.

-- 
Daniel Jacobowitz

Re: [patch/rfa] tweak patterns for annota3.exp

[Randolph Chung]

> Are you sure there's nothing but an extra \r\n?  It definitely passes
> for others, so I'd like to know where that came from.

yup... the log says:

signal SIGUSR1^M
^M
^Z^Zpost-prompt^M
Continuing with signal SIGUSR1.^M
^M
^Z^Zstarting^M
^M
^Z^Zframes-invalid^M
^M
^Z^Zbreakpoint 2^M
^M
Breakpoint 2, 0x000105d4 in handle_USR1 (sig=16) at /home/tausq/gdb/gdb-cvs/gdb/testsuite/gdb.base/annota3.c:18^M
^M
^Z^Zsource /home/tausq/gdb/gdb-cvs/gdb/testsuite/gdb.base/annota3.c:18:238:beg:0x105d4^M
^M
^Z^Zstopped^M
^M
^Z^Zpre-prompt^M
(gdb) ^M
^Z^Zprompt^M
PASS: gdb.base/annota3.exp: send SIGUSR1

i have no idea where that comes from either... 

> > address of the signal handler... i.e. i get 
> > 
> > #0  0x000105d4 in handle_USR1 (sig=16) at /home/tausq/gdb/gdb-cvs/gdb/testsuite/gdb.base/annota3.c:18
> > 
> > instead of what the script expected, which seems to be
> > #0  handle_USR1 (sig=16) at /home/tausq/gdb/gdb-cvs/gdb/testsuite/gdb.base/annota3.c:18
> 
> The extra address means we didn't put the breakpoint at the beginning
> of a line.  This could be a prologue skipper bug, a GCC bug, a general
> the-world-hates-us bug, or we could decide it wasn't a bug.  The
> testsuite seems to contain examples of all of the above.

mmmmm. gcc creates this:

.globl handle_USR1
        .type   handle_USR1, @function
.LFB3:
        .loc 1 18 0
handle_USR1:
        .PROC
        .CALLINFO FRAME=64,NO_CALLS,SAVE_SP,ENTRY_GR=3
        .ENTRY
        copy %r3,%r1
.LCFI0:
        copy %r30,%r3
.LCFI1:
        stwm %r1,64(%r30)
.LCFI2:
        stw %r26,-36(%r3)
        ldo 64(%r3),%r30
        ldwm -64(%r30),%r3
        bv,n %r0(%r2)
        .EXIT
        .PROCEND

we are breakpointing at the ldo insn, which seems to be correct from the
prologue analysis point of view. do you mean that the ".loc" should be
right before the ldo?

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [patch/rfa] tweak patterns for annota3.exp

[Daniel Jacobowitz]

On Sun, Dec 05, 2004 at 06:56:45PM -0800, Randolph Chung wrote:
> > Are you sure there's nothing but an extra \r\n?  It definitely passes
> > for others, so I'd like to know where that came from.
> 
> yup... the log says:
> 
> signal SIGUSR1^M
> ^M
> ^Z^Zpost-prompt^M
> Continuing with signal SIGUSR1.^M
> ^M
> ^Z^Zstarting^M
> ^M
> ^Z^Zframes-invalid^M
> ^M
> ^Z^Zbreakpoint 2^M
> ^M
> Breakpoint 2, 0x000105d4 in handle_USR1 (sig=16) at /home/tausq/gdb/gdb-cvs/gdb/testsuite/gdb.base/annota3.c:18^M
> ^M
> ^Z^Zsource /home/tausq/gdb/gdb-cvs/gdb/testsuite/gdb.base/annota3.c:18:238:beg:0x105d4^M
> ^M
> ^Z^Zstopped^M
> ^M
> ^Z^Zpre-prompt^M
> (gdb) ^M
> ^Z^Zprompt^M
> PASS: gdb.base/annota3.exp: send SIGUSR1
> 
> i have no idea where that comes from either... 

You could put a breakpoint on vfprintf_unfiltered to find out :-)

> mmmmm. gcc creates this:
> 
> .globl handle_USR1
>         .type   handle_USR1, @function
> .LFB3:
>         .loc 1 18 0
> handle_USR1:
>         .PROC
>         .CALLINFO FRAME=64,NO_CALLS,SAVE_SP,ENTRY_GR=3
>         .ENTRY
>         copy %r3,%r1
> .LCFI0:
>         copy %r30,%r3
> .LCFI1:
>         stwm %r1,64(%r30)
> .LCFI2:
>         stw %r26,-36(%r3)
>         ldo 64(%r3),%r30
>         ldwm -64(%r30),%r3
>         bv,n %r0(%r2)
>         .EXIT
>         .PROCEND
> 
> we are breakpointing at the ldo insn, which seems to be correct from the
> prologue analysis point of view. do you mean that the ".loc" should be
> right before the ldo?

There should be an _additional_ .loc before the ldo.  The rule for what
GDB expects is: one line note before the function, one after the
prologue.

-- 
Daniel Jacobowitz

Re: [patch/rfa] tweak patterns for annota3.exp

[Randolph Chung]

> You could put a breakpoint on vfprintf_unfiltered to find out :-)

hrm, so...

first we get the "frames-invalid\n" from:
      printf_unfiltered ("\n\032\032frames-invalid\n");
from annotate.c:234

then we get "\nBreakpoint" from
      ui_out_text (uiout, "\nBreakpoint ");
from breakpoint.c:2098

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [patch/rfa] tweak patterns for annota3.exp

[Randolph Chung]

> > we are breakpointing at the ldo insn, which seems to be correct from the
> > prologue analysis point of view. do you mean that the ".loc" should be
> > right before the ldo?
> 
> There should be an _additional_ .loc before the ldo.  The rule for what
> GDB expects is: one line note before the function, one after the
> prologue.

i've filed this as gcc bugzilla #18856. gcc-3.4 apparently does the
right thing... (i'm using gcc-3.3)

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/