Bug#728705: gdb fails on s390x with "Couldn't write registers: Invalid argument"
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: debian-s390@lists.debian.org
>
> 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 <schwidefsky@de.ibm.com>
| 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: stable@vger.kernel.org
| Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
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
aurelien@aurel32.net http://www.aurel32.net
Reply to: