Red Hat Bugzilla – Bug 127228
PTRACE_GETFPREGS reports bad x87 tag value
Last modified: 2015-01-04 17:07:36 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510
Description of problem:
The tag word value reported by PTRACE_GETFPREGS is not the value
that would be saved by an fsave instruction. There is code in the
i386/ptrace.c file to attempt to emulate the fsave tag word from
the fxsave 1 byte tag info plus the register contents, but something
isn't right about the emulation code, as it does not come up with
the same value. (I suspect something about the 15 levels of operator
precedence in C together with the gigantic collections of ands
and ors in the source with no parens has something to do with it,
but it is beyond my ability to actually parse the emulation code
in the kernel, or I'd provide a patch :-).
I'll be attaching a small sample program tag.c to demonstrate the bug
to this bugzilla. Note that this has to run on a machine new enough
for the kernel to be using fxsave rather than fsave (which is just
about all of them, but I thought I'd mention it).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. gcc -o tag tag.c && ./tag
Actual Results: The PTRACE_GETFPREG function returns 0x505f for the
Expected Results: The actual value should be 0x05af
Created attachment 101625 [details]
C test program to demonstrate bug
seems to do the right thing here on the latest 2.6.10 kernel.
Hmmm... Maybe athlon versus 686 has something to do with it? On my system:
Linux spike 2.6.10-1.737_FC3 #1 Mon Jan 10 13:50:10 EST 2005 i686 athlon i386
I just recompiled and ran the test and still get the wrong answer:
In child, about to send myself a SIGUSR1
Child fsave buffer looks like:
twd = 0x05af
Parent PTRACE_GETFPREGS buffer looks like:
twd = 0xffff505f
The same 05af versus 505f as always.
I must have misread the results last night.
Roland, any ideas ?
Created attachment 109853 [details]
fix for fxsave->fnsave format bug
For the record, there was no earthly reason I should have been expected to have
a clue about this. In fact, I didn't. But I puzzled it out with the hardware
book and some experimentation.
Fedora Core 2 has now reached end of life, and no further updates will be
provided by Red Hat. The Fedora legacy project will be producing further kernel
updates for security problems only.
If this bug has not been fixed in the latest Fedora Core 2 update kernel, please
try to reproduce it under Fedora Core 3, and reopen if necessary, changing the
product version accordingly.