[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 24/30] linux-user/openrisc: Use force_sig_fault, force_sig
From: |
Stafford Horne |
Subject: |
Re: [PATCH v2 24/30] linux-user/openrisc: Use force_sig_fault, force_sigsegv_for_addr |
Date: |
Wed, 22 Sep 2021 05:26:23 +0900 |
On Sun, Sep 19, 2021 at 10:49:26AM -0700, Richard Henderson wrote:
> On 8/24/21 10:17 AM, Peter Maydell wrote:
> > I think that EXCP_RANGE should for us be unreachable in user-only
> > mode (because it can only happen if the relevant bits in SR are
> > set, and SR is writeable only in supervisor mode, and its starting
> > value doesn't set these bits). So we could just delete the EXCP_RANGE
> > handling and let it hit the default g_assert_not_reached() case.
>
> If I also disable the SR case from gdbstub.
>
> > EXCP_FPE is more tricky -- this happens for FP exceptions, where
> > the enabling bit is in the FPCSR, which does appear to be writeable
> > from user mode. So either:
> > * our mtspr is wrong and should either be not allowing writes
> > to FPCSR in usermode (or at least sanitizing them)
> > * the Linux kernel for openrisc is wrong, because a userspace
> > program that sets FPCSR.FPEE can make it run into unhandled_exception()
> > and die(), and it should be doing something else, like delivering
> > a suitable SIGFPE
>
> I believe the kernel to be buggy. But it also point to the fact that no one
> has written fenv.h for or1k for musl, so no one has tried to use those bits.
Hi,
*On User Accessible FPCSR*
As per the spec FPCSR should not be accessible in user space. But...
I am currently working on the OpenRISC port for glibc, and at first I was
planning for FPU support but this was one thing that slowed me down.
For that reason I proposed an architecture change to allow setting fpcsr in user
space, it seems that is allowed by almost all other architectures:
https://openrisc.io/proposals/p17-user-mode-fpcsr
I think I could also simulate it in the kernel by catching the mtspr failure and
then performing it on behalf of the user if its for MTSPR.
At the moment I am going with softfpu until I can spend time on sorting out the
FPCSR issue.
*On QEMU*
When I started to develop the glibc FPU code, I put a patch into qemu to allow
for using mtspr and mfspr in user space:
branch:
https://github.com/stffrdhrn/qemu/commits/or1k-glibc
commit:
https://github.com/stffrdhrn/qemu/commit/dfa5331bf43f71535847c585a6b3f5779a422b13
User space access it not allowed as per trans_l_mfspr, trans_l_mfspr. I did not
post this upstream as it's not as per spec.
I hope it helps a bit.
-Stafford