Regression

[Pedro Alves]

On Tuesday 10 February 2009 15:47:23, Mark Kettenis wrote:
> I don't quite understand what's happening here, but I get the
> following new failure:
> 
> FAIL: gdb.base/annota1.exp: send SIGUSR1
> 

I see that too.

> and some more fallout from that (and similar failures in annota3.exp).
> It seems that if we've just hit a breakpoint and then do "signal
> SIGUSR1" we never enter the signal handler or ignore the breakpoint in
> the signal handler.

Here's the infrun log on i386-openbsd4.3:

 (gdb) b printf
 Breakpoint 1 at 0x1c000408
 (gdb) r
 Starting program: /net/home/pedro/gdb/baseline/build-openbsd43/gdb/testsuite/gdb.base/annota1

 Breakpoint 1, printf (fmt=0x3c000001 "value is %d\n") at /usr/src/lib/libc/stdio/printf.c:43
 43      /usr/src/lib/libc/stdio/printf.c: No such file or directory.
         in /usr/src/lib/libc/stdio/printf.c
 (gdb) p $pc
 $1 = (void (*)()) 0xa43a633 <printf+19>
 (gdb) b handle_USR1
 Breakpoint 2 at 0x1c000613: file ../../../src/gdb/testsuite/gdb.base/annota1.c, line 18.
 (gdb) set debug infrun 1
 (gdb) signal SIGUSR1
 Continuing with signal SIGUSR1.
 infrun: clear_proceed_status_thread (process 27276)
 infrun: proceed (addr=0xffffffff, signal=30, step=0)
 infrun: resume (step=1, signal=30), trap_expected=1
 infrun: wait_for_inferior (treat_exec_as_sigtrap=0)
 infrun: target_wait (-1, status) = 27276, status->kind = stopped, signal = SIGTRAP
 infrun: infwait_normal_state
 infrun: TARGET_WAITKIND_STOPPED
 infrun: stop_pc = 0xeff4636

Here, it seems like telling BSD to single-step, and, to deliver
a signal at the same time, just single-steps, resulting in a SIGTRAP.

 infrun: no stepping, continue
 infrun: resume (step=0, signal=0), trap_expected=0
 infrun: prepare_to_wait
 value is 7
 infrun: target_wait (-1, status) = 27276, status->kind = stopped, signal = SIGTRAP
 infrun: infwait_normal_state
 infrun: TARGET_WAITKIND_STOPPED
 infrun: stop_pc = 0xeff4633
 infrun: BPSTAT_WHAT_STOP_NOISY
 infrun: stop_stepping
 
 Breakpoint 1, printf (fmt=0x3c00000e "my_array[2] is %d\n") at /usr/src/lib/libc/stdio/printf.c:43
 43      in /usr/src/lib/libc/stdio/printf.c
 (gdb)







> 
> I'm somewhat surprised to hear that the same test doesn't fail on x86
> Linux for you.

It doesn't for me.

-- 
Pedro Alves