Re: [Qemu-devel] Sparc port

[Fabrice Bellard]

David S. Miller wrote:
>    From: Fabrice Bellard <address@hidden>
>    Date: Sun, 08 Jun 2003 12:52:59 +0200
>
>    David S. Miller wrote:
>    > 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.
>    
> Then we probably should, as you seem to suggest, generate the helper
> functions just like we generate code to execute x86 instructions.

I made the necessary patches so that test-i386 works as a dynamically 
linked program. Unfortunately, I was forced to use -mflat on the file 
'helper-i386.c' in order to get correct local variables modifications. I 
know this is bad, but I see no other simple solution. If someday a 
better code generator is used, the proper solution will be to save the 
modified x86 register in the 'env' structure before calling a helper 
function from the generated code.

>    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).
>    
> "si_info" is passed into the thread, but unfortunately only when
> an rt signal frame is used.
> I can't change the existing non-rt signal frame layout else I'll break
> a ton of applications, and in particular GCC exception handling.

QEMU uses an rt signal, so there is no problem if it is only available 
in that case. It would be logical to add the write info in siginfo_t as 
the fault address is already saved in it.

Currently I made the same hack as Falk did on Alpha... it seems to work, 
at least on test-i386.

Is there any advantages in using QEMU as a sparc64 executable ? Do you 
think it would allow to let the full lower 32 bit address space to the 
x86 process ?

Fabrice.