[Top][All Lists]
[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.
helloworld.c
Description: Text Data
helloworld.sparc32
Description: Binary data
[Qemu-devel] [PATCH] Remove blank elements in tcg_target_reg_alloc_order[], Stuart Brady, 2008/03/07