[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Sparc port
From: |
Fabrice Bellard |
Subject: |
Re: [Qemu-devel] Sparc port |
Date: |
Sun, 08 Jun 2003 12:52:59 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.1) Gecko/20020828 |
David S. Miller wrote:
From: Fabrice Bellard <address@hidden>
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.