Red Hat Bugzilla – Bug 508955
SSE registers and ptrace problem
Last modified: 2009-07-08 08:45:23 EDT
Description of problem:
I don't have a small test case yet (I'll attach it when I do), but something
in the vicinity of the SSE registers and debugging operations is screwed
up. I have a debugger regression test that fails in x86_64 fedora 11 and
passes on the exact same machine running the exact same debugger in
x86_64 fedora 10.
The symptom is that a xmm register I modify with ptrace pokeuser
does not show up with the same value in the process when I run it later,
but the details are complex, and I haven't made a simple case fail yet.
I just thought I'd go ahead and create this bugzilla in case someone else
runs across the problem or knows it is already fixed in an upcoming kernel.
Version-Release number of selected component (if applicable):
every time in my complicated testbed
Steps to Reproduce:
2.see failure (no much help, I know).
Just to give an example, the debugged process that has been modified
winds up printing:
patched output = 5.4902e-315
When if the register modification had worked, it would have printed:
patched output = 47
On fedora 10, the kernel that worked was:
There are also many other linux distributions which run the test with
(In reply to comment #1)
> There are also many other linux distributions which run the test with
> no failures.
With 2.6.29 kernels?
Probably not. I think fedora 11 is the only one with a 2.6.29 kernel,
but I'm also very confused by what I'm seeing while trying to track
down the specific bug - I still don't have a clue what is actually
going wrong, sometimes I think it might be a gcc code generation
problem rather than a kernel problem - fedora 11 may also be the only linux
I've tried it on with a 4.4 gcc (I haven't checked for sure).
OK, I'm still confused as ever about why this only fails on fedora 11,
but I'm now pretty positive that whatever is going on has nothing to do
with the kernel, so I'm gonna close this as notabug.
Sorry for the noise :-).