[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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]