[Qemu-devel] [PATCH] Fix dyngen failure on PPC.

[Qemu-devel] [PATCH] Fix dyngen failure on PPC.

[David Woodhouse]

GCC 4 occasionally generates functions with the 'blr' somewhere in the
middle and a branch at the end.

--- qemu-0.7.0/dyngen.c.orig	2005-04-30 11:59:05.000000000 +0100
+++ qemu-0.7.0/dyngen.c	2005-04-30 12:00:11.000000000 +0100
@@ -1396,11 +1395,13 @@ void gen_code(const char *name, host_ulo
 #elif defined(HOST_PPC)
     {
         uint8_t *p;
+        uint32_t insn;
         p = (void *)(p_end - 4);
         if (p == p_start)
             error("empty code for %s", name);
-        if (get32((uint32_t *)p) != 0x4e800020)
-            error("blr expected at the end of %s", name);
+        insn = get32((uint32_t *)p);
+        if (insn != 0x4e800020 && (insn & 0xfc000002) != 0x48000000)
+            error("blr or b expected at the end of %s", name);
         copy_size = p - p_start;
     }
 #elif defined(HOST_S390)

-- 
dwmw2

Re: [Qemu-devel] [PATCH] Fix dyngen failure on PPC.

[Paul Brook]

On Saturday 30 April 2005 12:10, David Woodhouse wrote:
> GCC 4 occasionally generates functions with the 'blr' somewhere in the
> middle and a branch at the end.
>
> --- qemu-0.7.0/dyngen.c.orig	2005-04-30 11:59:05.000000000 +0100
> +++ qemu-0.7.0/dyngen.c	2005-04-30 12:00:11.000000000 +0100
> @@ -1396,11 +1395,13 @@ void gen_code(const char *name, host_ulo
>  #elif defined(HOST_PPC)
>      {
>          uint8_t *p;
> +        uint32_t insn;
>          p = (void *)(p_end - 4);
>          if (p == p_start)
>              error("empty code for %s", name);
> -        if (get32((uint32_t *)p) != 0x4e800020)
> -            error("blr expected at the end of %s", name);
> +        insn = get32((uint32_t *)p);
> +        if (insn != 0x4e800020 && (insn & 0xfc000002) != 0x48000000)
> +            error("blr or b expected at the end of %s", name);
>          copy_size = p - p_start;
>      }
>  #elif defined(HOST_S390)

This is not correct.
If the blr is not at the end of the function, things will break.
dyngen assumes the last instruction is the only return instruction in the 
function. This allows it to remove the blr insn and concatenate multiple 
functions together.

This basically only ever worked because gcc could be coerced into generating 
relatively simple code. GCC4 contains much more aggressive high level 
optimizers, so this is no longer possible.

Paul

Re: [Qemu-devel] [PATCH] Fix dyngen failure on PPC.

[Flavio Visentin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> This is not correct.
> If the blr is not at the end of the function, things will break.

[SNIP]

> This basically only ever worked because gcc could be coerced into generating 
> relatively simple code. GCC4 contains much more aggressive high level 
> optimizers, so this is no longer possible.

I don't know almost anything about gcc, so I'm asking two questions:

1) Isn't there any kind of compiler directive to force no optimization
only for a portion of the code?

2) If there aren't such directives is it possible to link together
optimized obj with not optimized obj? In this case you could group
functions that require no optimization and link them with the other
optimized code.

Maybe I asked 2 dumb questions, but I'm courious and I'd like to learn
something new :-)

TNX

P.S. I apologize for my bad English :-)

- --
Flavio Visentin

|                     \|||/
|                    @/0.0\@
|                     \ - /
+------------------oOOo---oOOo------------------

There are only 10 types of people in this world:
those who understand binary, and those who don't.

GPG Key: http://www.zipman.it/gpgkey.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCdTj0usUmHkh1cnoRAs3hAJ48/9uEbjEqNTsa24mKm6Ol62774ACdGpnF
N+EC/lngLa6oytEfDVUO3eA=
=lVHN
-----END PGP SIGNATURE-----

Re: [Qemu-devel] [PATCH] Fix dyngen failure on PPC.

[Paul Brook]

On Sunday 01 May 2005 21:15, Flavio Visentin wrote:
> > This is not correct.
> > If the blr is not at the end of the function, things will break.
>
> [SNIP]
>
> > This basically only ever worked because gcc could be coerced into
> > generating relatively simple code. GCC4 contains much more aggressive
> > high level optimizers, so this is no longer possible.
>
> I don't know almost anything about gcc, so I'm asking two questions:
>
> 1) Isn't there any kind of compiler directive to force no optimization
> only for a portion of the code?

Optimiziation is controlled on a per-file bases.

> 2) If there aren't such directives is it possible to link together
> optimized obj with not optimized obj? In this case you could group
> functions that require no optimization and link them with the other
> optimized code.

Linking together objects compiled with and without optimization isn't a 
problem, however...

Disabling optimization isn't really an option because (a) it causes other 
problems, and (b) the code generate is awfully slow.
The real solution is to teach qemu how to generate native code from and remove 
dyngen altogether, but that's a lot of work. Look in the list archives for 
more details.

Paul

Re: [Qemu-devel] [PATCH] Fix dyngen failure on PPC.

[Jonas Maebe]

On 01 May 2005, at 19:04, Paul Brook wrote:

> This is not correct.
> If the blr is not at the end of the function, things will break.
> dyngen assumes the last instruction is the only return instruction in 
> the
> function. This allows it to remove the blr insn and concatenate 
> multiple
> functions together.

Can't we on PPC just replace all blr's with plain branches to the 
instruction after end of the function? (since all instructions are 32 
bit long)


Jonas

Re: [Qemu-devel] [PATCH] Fix dyngen failure on PPC.

[Paul Brook]

On Sunday 01 May 2005 21:29, Jonas Maebe wrote:
> On 01 May 2005, at 19:04, Paul Brook wrote:
> > This is not correct.
> > If the blr is not at the end of the function, things will break.
> > dyngen assumes the last instruction is the only return instruction in
> > the
> > function. This allows it to remove the blr insn and concatenate
> > multiple
> > functions together.
>
> Can't we on PPC just replace all blr's with plain branches to the
> instruction after end of the function? (since all instructions are 32
> bit long)

Yes, that should be work for ppc.

Obviously this doesn't help on x86/amd64 where a jump is longer than a ret. 
you would have to copy the preceeding instruction[s] to make room for the 
branch. You'd then need to redirect any jumps directly to the ret 
instruction, and make them point at the copy.

Sparc may have similar problems because of jump delay slots (a jump is 
effectively two instructions long.

Arm needs a bit of logic to follow jumps and figure out where the end of the 
function is (ie. where the constant pool starts), but other that than the 
same trick should work.

Overall it sounds like a tractable problem. It shouldn't matter if this 
analysis takes a while because it's don'e while building qemu, not at 
runtime.

Paul