[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: 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: