qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Questions/comments on TCG


From: Blue Swirl
Subject: Re: [Qemu-devel] Questions/comments on TCG
Date: Sat, 8 Mar 2008 16:07:49 +0200

On 3/7/08, Blue Swirl <address@hidden> wrote:
> On 3/7/08, Stuart Brady <address@hidden> wrote:
>  > On Fri, Mar 07, 2008 at 08:47:03PM +0200, Blue Swirl wrote:
>  >  > On 3/7/08, Stuart Brady <address@hidden> wrote:
>  >
>  > > > tcg_target_reg_alloc_order[] has 32 elements, but only 14 are used.
>  >  > >  The rest hold 0, specifying TCG_REG_G0.
>  >  >
>  >  > I see. That could be asking for trouble.
>  >
>  >
>  > Possibly not, as g0 is marked as reserved, but it looks to me like bug,
>  >  regardless of whether it causes any harm, so I've submitted a patch.
>  >
>  >
>  >  > > I don't understand -- o7 is required when returning in exit_tb, so if 
> it
>  >  > >  is used, it must be saved and restored.
>  >  >
>  >  > Not exit_tb, but call.
>  >
>  >
>  > Right, op_call does need to link, and that clobbers the link register,
>  >  so it must be restored -- but I've a feeling that this isn't happening.
>  >  I expect you could copy o7 to/from i5 before/after the call (or jmpl)...
>  >  although I'm not sure if you'd also need to save the frame pointer.
>
>
> Another possibility is to add function epilogue with save and add
>  restore to ret (or use v9 return).

I added the save and restore instructions, because if the generated
code made any calls, the registers were overwritten.

Currently on Sparc64 host a small helloworld program executes until
the system call, then Qemu dies with illegal instruction. It looks
like this is caused by setjmp/longjmp register mangling bugs in Linux
glibc, my workaround does not help. I'd be interested to hear if this
works any better on Solaris/Sparc or *BSD/Sparc. On Sparc32 TB linking
does not work, so Qemu dies on TB switch.

Attachment: helloworld.c
Description: Text Data

Attachment: helloworld.sparc32
Description: Binary data


reply via email to

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