Hi Maciej,
On Thursday, 15 June 2017 19:55:26 PDT Maciej W. Rozycki wrote:
> On Mon, 5 Jun 2017, Paul Burton wrote:
> > This series tidies up support for floating point a little, then
> > introduces support for disabling it via Kconfig. The end result is that
> > it becomes possible to compile a kernel which does not include any
> > support for userland which makes use of floating point instructions -
> > meaning that it never enables an FPU & does not include the FPU
> > emulator. The benefit of this is that if you know your userland code
> > will not use FP instructions then you can shrink the kernel by around
> > 65KiB.
> >
> > Applies atop v4.12-rc4.
> >
> > Paul Burton (5):
> > MIPS: Remove unused R6000 support
> > MIPS: Move r4k FP code from r4k_switch.S to r4k_fpu.S
> > MIPS: Move r2300 FP code from r2300_switch.S to r2300_fpu.S
> > MIPS: Remove unused ST_OFF from r2300_switch.S
> > MIPS: Allow floating point support to be disabled
>
> Doesn't ptrace(2) require suitable updates for requests that deal with
> the FP context?
I mentioned in the commit message for patch 5 that removing the actual context
fields & ptrace access to them could be done as a further improvement.
> Preferably along with the last change (or maybe ahead of
> it) so that we don't have a kernel revision that presents rubbish to the
> userland (of course tools like GDB will have to be updated accordingly to
> cope, but that's out of scope for Linux itself).
Well, as-is ptrace would still let you read & write to FP registers if you
try, it's just those values will never be used. Are you opposed to that
behaviour? If we do later remove the context entirely then presumably ptrace
would either read 0 or return an error, and ignore writes or return an error -
I suppose if we want to ensure consistent behaviour for that potential future
change then we could choose one of those options & do that here.
In practice I'm not sure I see much benefit - if a debugger wants to write to
context corresponding to registers that just aren't there then letting it
doesn't seem like a big problem. Do you disagree? Note that we already allow
this for hi & lo registers on r6 for example - ptrace will freely read/write
the context even though the registers don't exist.
> Also how about those prctl(2) calls that also operate on FP state?
Patch 5 has them return -EOPNOTSUPP, which is consistent with behaviour when
attempting to set an unsupported mode.
Thanks,
PaulAttachment:
signature.asc
Description: This is a digitally signed message part.
