[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 18:21:58 +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: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 ?


reply via email to

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