Re: Signal/gdb oddity in 2.5.61

From: Daniel Jacobowitz (dan@debian.org)
Date: Sun Feb 16 2003 - 17:10:23 EST


On Sun, Feb 16, 2003 at 07:15:43PM +0000, Russell King wrote:
> Hi,
>
> I'm seeing some weird behaviour with signal handling/gdb on 2.5.61:
>
> [root@assabet /root]$cat /dev/zero > /dev/null &
> [1] 132
> [root@assabet /root]$gdb /bin/cat
> GNU gdb 5.0
> Copyright 2000 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "armv4l-rmk-linux"...(no debugging symbols found)...
> (gdb) attach 132
> Attaching to program: /bin/cat, Pid 132
> Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
> Loaded symbols for /lib/libc.so.6
> Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
> Loaded symbols for /lib/ld-linux.so.2
> 0x20027a0 in _IO_putc ()
> (gdb) stepi
>
> Program received signal SIGSTOP, Stopped (signal).
> 0x20027a0 in _IO_putc ()
> (gdb)
> 0x20027a4 in _IO_putc ()
> (gdb)
> 0x4008d154 in putc () from /lib/libc.so.6
> (gdb) quit
>
> Notice the "Program received signal SIGSTOP".
>
> Asking for the process list via <sysrq>t shows the following after
> attaching gdb:
>
> cat T C023CE94 3263624 132 135 (NOTLB)
> [<c023cb98>] (schedule+0x0/0x3a0)
> from [<c024d020>] (get_signal_to_deliver+0x1c0/0x3e4)
> [<c024ce60>] (get_signal_to_deliver+0x0/0x3e4)
> from [<c0226a00>] (do_signal+0x5c/0x13c)
> [<c02269a4>] (do_signal+0x0/0x13c)
> from [<c0226b10>] (do_notify_resume+0x30/0x34)
> [<c0226ae0>] (do_notify_resume+0x0/0x34)
> from [<c0222350>] (work_pending+0x1c/0x28)
>
> and after the first stepi:
>
> cat T C023CE94 3263624 132 135 (NOTLB)
> [<c023cb98>] (schedule+0x0/0x3a0)
> from [<c024cbb4>] (finish_stop+0xb0/0xc8)
> [<c024cb04>] (finish_stop+0x0/0xc8)
> from [<c024ce54>] (do_signal_stop+0x288/0x294)
> [<c024cbcc>] (do_signal_stop+0x0/0x294)
> from [<c024d184>] (get_signal_to_deliver+0x324/0x3e4)
> [<c024ce60>] (get_signal_to_deliver+0x0/0x3e4)
> from [<c0226a00>] (do_signal+0x5c/0x13c)
> [<c02269a4>] (do_signal+0x0/0x13c)
> from [<c0226b10>] (do_notify_resume+0x30/0x34)
> [<c0226ae0>] (do_notify_resume+0x0/0x34)
> from [<c0222350>] (work_pending+0x1c/0x28)
>
> subsequent stepi's appear as per the first trace above.

This is a consequence of ARM's separate get_signal_to_deliver.
Roland's changes for group stops require code in get_signal_to_deliver,
so if you aren't using the common version, you're out of luck.

I think you'll have to either update yours to match, or use the new
hooks David Miller added to use the common get_signal_to_deliver.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sun Feb 23 2003 - 22:00:15 EST