Bug#728705: gdb fails on s390x with "Couldn't write registers: Invalid argument"
reassign 728705 src:linux 3.2.35-1
affects 728705 gdb
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@example.com
> 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
> 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:
> 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
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 <firstname.lastname@example.org>
| 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@example.com
| Signed-off-by: Martin Schwidefsky <firstname.lastname@example.org>
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