Re: Problems with signals and illegal instructions in user mode

[Peter Maydell]

On Thu, 23 Apr 2020 at 10:46, Gabe Black <address@hidden> wrote:
>
> Thanks for looking into this. Is there any way to fix these problems? IE to 
> tell QEMU to not act like it has coprocessor 1? For that one in particular, 
> there are a lot of binaries out there which already try to use that 
> instruction, and changing them would be difficult or impossible for reasons 
> like checkpointed systems with the existing binary, etc. I'm supposing the 
> fix for SPARC would be to implement that support in QEMU somehow. I might be 
> able to do that? But I'd have to find the time from somewhere :-/ Is there 
> any way to fix the SIGSEGV error code? It sounds like I may just have to make 
> my test more lenient. That's not ideal since functionally it's pretty 
> important that there's really a page there, but I guess when I check in 
> /proc/XXX/maps that will cover it?

There's no way to configure out the FPA emulation, and I'm
not hugely enthusiastic about adding that to work around
a misuse of the coprocessor space by some group of
nonstandard binaries: this has always been walking on
thin ice. (The local hack to remove it is trivial: ifdef
out the EmulateAll() call in linux-user/arm/cpu_loop.c...)

The sparc signal handling fix is conceptually straightforward
(add the relevant code to linux-user/sparc/signal.c to set
up and tear down the signal frames; this is similar to the
kernel's code to do the same job). As you say it's just
a matter of somebody having the time and motivation.

The ACCERR vs MAPERR bug is a bit more complicated because
it's a plumbing problem so there's a design question of the
best routing for the plumbing, which goes from common code
in accel/tcg/user-exec.c:handle_cpu_signal() to per-target
code in the tlb_fill() method which updates per-target
data structures which eventually get read by per-target
code in linux-user/$ARCH/cpu_loop.c which is what queues
the SEGV. Some targets (eg ppc) seem to have some attempt
to distinguish ACCERR from MAPERR already but this must
be broken because the handle_cpu_signal() code doesn't
provide them with the necessary information to make the
distinction.

thanks
-- PMM