Re: [Qemu-devel] Sparc port

[Fabrice Bellard <fabrice.bellard@free.fr>]

David S. Miller wrote:
>    From: Fabrice Bellard <fabrice.bellard@free.fr>
>    Date: Sun, 08 Jun 2003 12:10:22 +0200
> 
>    I have two ideas :
>    
>    1) We use -mflat for exec-i386.c and helper-i386.c but not for op-i386.c 
>    to avoid gcc bugs. Now that op-i386.c only contains opcodes, the code 
>    inside should almost look like '-mflat' code.
>    
> -mflat doesn't work, gcc doesn't obey -fno-delayed-branch when
> -mflat is specified and that basically makes it useless.

My suggestion was to use it without -fno-delayed-branch: only the 
helpers and exec-i386.c would be compiled with it. op-i386.c would still 
stay in no-flat mode.

> Also, this feature of GCC is scheduled for deprecation.

OK. This is a good reason for not using it !

>    2) We can patch cpu_exit_loop() by doing the right number of restores 
>    (maybe a single longjmp would suffice as l0...l7 are still saved.
> 
> This might work.   
> 
> I think all things that generated code could call should marked as
> ONLY being invoked from generated code, and furthermore have a very
> fixed environment that we can rely upon.

I am trying to do that. In the long term, maybe a proper code generator 
will be used, but the function helpers will stay the same, so we must 
find a good solution for them.

> It is the only clean way to deal with this sparc issue in the long
> term.

I still have a problem: if a helper function modifies an x86 register 
which is in a sparc register (say EAX in %l0), then it cannot work 
because save/restore are done at the beginning of the helper.

BTW, another question: how can we know on Sparc if a SIGSEGV or SIGBUS 
was generated because of a read or a write ? The Linux kernel has the 
info but it does not seem to be copied to user space. It may be 
interesting to find a standard way to indicate if it is a read or write 
which caused the fault (using a field in siginfo_t would be nice).

Fabrice.