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): kernel-2.6.6-1.435.2.3 How reproducible: Always Steps to Reproduce: 1. gcc -o tag tag.c && ./tag Actual Results: The PTRACE_GETFPREG function returns 0x505f for the tag word. Expected Results: The actual value should be 0x05af Additional info:
Created attachment 101625 [details] C test program to demonstrate bug
seems to do the right thing here on the latest 2.6.10 kernel. closing.
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 GNU/Linux 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. Thank you.