[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: [RESEND] TCG breakage if TARGET_LONG_BITS > HOST_LONG_B
From: |
Fabrice Bellard |
Subject: |
[Qemu-devel] Re: [RESEND] TCG breakage if TARGET_LONG_BITS > HOST_LONG_BITS |
Date: |
Wed, 13 Feb 2008 00:29:36 +0100 |
User-agent: |
Thunderbird 1.5.0.9 (X11/20070212) |
Alexander Graf wrote:
> This is a resend of a mail I sent to the list on 2008/02/06. I felt it
> rather disturbing, yet normal that nobody cared about Mac OS X host
> support, but this concerns all x86 host OSs, so I believe this deserves
> some discussion.
>
> Hi,
>
> I've been trying to get the new TCG approach running on an i386 host. It
> works when I use gcc3 (miraculously as I will explain later), but fails
> on gcc4.
>
> On boot the very first instruction that gets issued is the ljmp to the
> bios:
> [...]
> 1. Why is gcc3 generating code, that does not use ebx?
> 2. Why does movi_i64 generate code that only accesses registers? I have
> not been able to find any branch in the tcg code generator for movi_ixx
> that generates movs to memory addresses.
>
> The whole issue could be easily fixed by using registers, but putting
> the call into inline assembly, telling gcc that this call clobbers all
> the registers. I do not know if this is the expected behavior though, so
> I think I'd rather ask before doing any patches.
The fact that it works in some cases is a miracle. The right solution is
to use a global TB prologue and epilogue which saves and restores callee
saved registers (it is in the tcg TODO list).
A temporary solution before that would be to mark ebx, esi and edi as
reserved registers if TARGET_LONG_BITS > HOST_LONG_BITS.
Fabrice.