[Qemu-devel] Sparc port

[Qemu-devel] Sparc port

[Fabrice Bellard]

I am now trying to make the Sparc port work again. I added a sparc 
disassembler so that debugging is easier.

In order to support direct block chaining, it is necessary that no 
prologue or epilogue are added in the generated code. It should be easy 
to do by moving the add/sub sp/fp in the call code in exec-i386.c.

Moreover, the 'restore' used in exec-i386.c in cpu_loop_exit() is not 
safe because we cannot be sure that there was exactly one call level.

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.

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.


Another more general idea for all archs is to call the generated code 
with a 'jump' instead of doing a call. It would be marginaly more 
complicated and would permit more optimisation (currently, on PowerPC 
and Alpha the code is very inefficient if a helper is called because the 
return address must be saved in a new generated stack frame).

Fabrice.

Re: [Qemu-devel] Sparc port

[David S. Miller]

   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.

Also, this feature of GCC is scheduled for deprecation.

   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.

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

Re: [Qemu-devel] Sparc port

[Fabrice Bellard]

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.

Re: [Qemu-devel] Sparc port

[David S. Miller]

   From: Fabrice Bellard <fabrice.bellard@free.fr>
   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.

   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.

Re: [Qemu-devel] Sparc port

[Falk Hueffner]

Fabrice Bellard <fabrice.bellard@free.fr> writes:

> BTW, another question: how can we know on Sparc if a SIGSEGV or
> SIGBUS was generated because of a read or a write ?

Probably in the same ugly way I tried it in the Alpha port: look at
the faulting instruction and disassemble it.

> 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).

Yes, that would be really nice. There are many uses for this.

-- 
	Falk

Re: [Qemu-devel] Sparc port

[Fabrice Bellard]

David S. Miller wrote:
>    From: Fabrice Bellard <fabrice.bellard@free.fr>
>    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.

Re: [Qemu-devel] Sparc port

[David S. Miller]

   From: Fabrice Bellard <fabrice.bellard@free.fr>
   Date: Sun, 08 Jun 2003 18:21:58 +0200
   
   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 ?

Yes, but we need to use the correct code model so that
the qemu executable and linked in libraries sits at or above 4GB.

Even though I coded all of the sparc GCC support for all these
code models, I have no idea how to foce the final executable to
be force linked to use addresses > 4GB.   Someone will need to
experiment here.