Description of problem: On a GDB testcase was found i386 debugger running on x86_64 kernel accidentally causes ERESTARTSYS to be returned in errno in the process being debugged. FIXME: It is not reproducible on an i386 debugger on an i386 kernel. It is not reproducible on an x86_64 debugger on an x86_64 kernel. It is the same Bug as Bug 434995 but in that case a raise() in the called function was enough. Now for the reproducibility one has to do some int3 (->SIGTRAP) or an invalid memory access (->SIGSEGV). Version-Release number of selected component (if applicable): kernel-2.6.29.5-191.fc11.x86_64 (FAILs) kernel-2.6.31-0.38.rc1.git7.fc12.x86_64 (FAILs) How reproducible: Always. Steps to Reproduce: wget http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/tests/ptrace-tests/tests/erestartsys-trap.c?cvsroot=systemtap; gcc -o erestartsys-trap erestartsys-trap.c -Wall -ggdb2 -D_GNU_SOURCE -m32 -lutil; ./erestartsys-trap; echo $? Actual results: 1 Expected results: 0 Additional info:
PASS for an i386 debugger on an i386 kernel (as the former Bug). Tested only in KVM (on kernel-2.6.29.5-191.fc11.x86_64).
Reproduced on upstream v2.6.31-5510-gde55a89
The key issue is that in the "restored" state, the thread is not on the syscall-exit path in the kernel after a 32-bit syscall, but is later in the vanilla exception-signal path back to user mode. This means TS_COMPAT is not set and so the kernel doesn't think orig_ax/ax refer to a 32-bit syscall where it would sign-extend 32-bit values. I'll figure out the fix upstream.
Created attachment 361587 [details] proposed fix
Please review the explanation and caveats in the log/comments of the patch before I submit it upstream.
Stupid question. This patch simply removes R32(eax, ax), this means the debugger can change orig_eax but not eax?
(In reply to comment #7) > Stupid question. This patch simply removes R32(eax, ax), this means > the debugger can change orig_eax but not eax? Oops! Please ignore, I didn't notice "case offsetof(struct user32, regs.eax):" below. This all looks correct to me, but my understanding of this magic is very limited.
No GDB testsuite regressions, gdb.base/interrupt.exp got fixed for crossarch runs, OK from me, thanks.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fixed in: kernel-2.6.34.7-61.fc13.x86_64