[PATCH 0/2] More FCSR handling fixes

From: Maciej W. Rozycki
Date: Fri Oct 28 2016 - 03:19:30 EST


Hi,

Here are some further fixes to our FCSR handling. Just 2 changes at this
time.

The first, very small one, closes an issue where a write made with
ptrace(PTRACE_POKEUSR, ...) to FCSR does not mark the FP context as used.
This is the legacy interface, seldom used these days, having been largely
replaced with ptrace(PTRACE_SETFPREGS, ...), so the problem may have
escaped easily. Fixed now.

The second, larger one, addresses the handling of the Cause bits, by
letting them remain set in some cases, making their semantics more
consistent with what hardware does when undisturbed; a SIGFPE signal is
sent if appropriate where previously it was missed.

This change is not final as in some cases, specifically in the FP context
of SIGFPE's signal frame, active Cause bits that match Enable bits will
still be recorded as clear even though they were originally set, being the
reason for the signal. Consequently the signal will not retrigger if the
handler returns with the FP context unchanged in the signal frame. This
is unlike with other signals triggered by a hardware exception which do
require a corrective action if a return is intended rather than an escape
via `longjmp' or suchlike and which is what one would expect here as well.

I plan to address this final issue with a further change in the future,
however I have not started this effort yet and I don't have a schedule
set. Meanwhile this change is I believe a step in the right direction.

Details of both changes have been provided with individual patch
descriptions.

While making these changes I have noticed a bunch of bitrot issues we
have with the handling of the FP context in signal frames with MIPS I-II
processors. I will submit corrections as a separate patch series.

Questions or comments are welcome, as usually, and otherwise please queue
for the next merge cycle.

Maciej