reassign 728705 src:linux 3.2.35-1 affects 728705 gdb thanks On Mon, Nov 04, 2013 at 02:35:39PM +0100, Thibaut Paumard wrote: > Package: gdb > Version: 7.6.1-1 > Severity: important > X-Debbugs-CC: [email protected] > > Dear Maintainer, > > gdb seems to be completely useless on s390x. I tried running it against > various executables (both buggy and sane). gdb seems to launch the > executable, however the subprocess doesn't seem to be doing anything. > gdb just gives a message, but it does not even seem to consider the > situation fatal and just seats there, apparently considering that the > subprocess is running faultlessly. Example session on "echo foo", notice > how "foo" is not echoed: > > ________________ GDB SESSION _______________________ > > (sid_s390x-dchroot)thibaut@zelenka:~$ gdb --args echo foo > GNU gdb (GDB) 7.6.1 (Debian 7.6.1-1) > Copyright (C) 2013 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "s390x-linux-gnu". > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>... > Reading symbols from /bin/echo...(no debugging symbols found)...done. > (gdb) run > Starting program: /bin/echo foo > Couldn't write registers: Invalid argument. > (gdb) bt > Target is executing. > (gdb) quit > A debugging session is active. > > Inferior 1 [process 18228] will be killed. > > Quit anyway? (y or n) y > (sid_s390x-dchroot)thibaut@zelenka:~$
This is actually a kernel issue, affecting only a few stable branches, due to the following patch being backported without a few other related patches: | commit fa968ee215c0ca91e4a9c3a69ac2405aae6e5d2f | Author: Martin Schwidefsky <[email protected]> | Date: Wed Nov 7 10:44:08 2012 +0100 | | s390/signal: set correct address space control | | If user space is running in primary mode it can switch to secondary | or access register mode, this is used e.g. in the clock_gettime code | of the vdso. If a signal is delivered to the user space process while | it has been running in access register mode the signal handler is | executed in access register mode as well which will result in a crash | most of the time. | | Set the address space control bits in the PSW to the default for the | execution of the signal handler and make sure that the previous | address space control is restored on signal return. Take care | that user space can not switch to the kernel address space by | modifying the registers in the signal frame. | | Cc: [email protected] | Signed-off-by: Martin Schwidefsky <[email protected]> For the 3.2 branch, it has been introduced in version 3.2.35. I have contacted the author of the patch to ask him what is the best option to fix the issue. In the meantime, I am reassigning the bug to the linux package. -- Aurelien Jarno GPG: 4096R/1DDD8C9B [email protected] http://www.aurel32.net -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
