Re: [Qemu-devel] get_func() hangs with gcc 3.4.2 on MinGW and WinXP host

[Jim C. Brown]

On Sat, Dec 18, 2004 at 03:59:38PM +0100, Johannes Schindelin wrote:
> Hi,
> 
> On Fri, 17 Dec 2004, Jim C. Brown wrote:
> 
> > On Sat, Dec 18, 2004 at 01:09:26AM +0100, Johannes Schindelin wrote:
> > > Hi,
> > >
> > > it would be better to fix
> > > the compilation of op.c, so that you really can chain the op_* functions.
> > > What I mean: if you work on it, you could as well do it such that you gain
> > > the most (performance) of it.
> > >
> > > Ciao,
> > > Dscho
> > >
> >
> > >From what I understand, this is outright impossible with later versions of
> > gcc. In order to do what you want, you would have to write the code purely
> > in assembler.
> 
> What do new gcc's do? Why is it impossible to chain the code?

Originally, the op_* functions for qemu were written so that they would have the
machine code and then the rets at the very end of the function. qemu could
then just chain them together by stripping the rets.

gcc now rearranges the generated code around, and reserves the right to stick in
extra rets any place it wants, not just the very end, which makes them very hard
to strip off. I asked another developer about the difficulty of doing this, and
was told that it would be easier to write a C compiler just for op.c from
scratch.

> Do you have
> an example object file, or even better, an assembly snippet?

Afraid not.

> 
> Ciao,
> Dscho
> 

On Fri, Dec 17, 2004 at 07:56:27PM +0100, Juergen Lock wrote:
> On Thu, Dec 16, 2004 at 01:37:53AM +0000, Johannes Schindelin wrote:
> > Hi,
> > 
> > On Wed, 15 Dec 2004, Jim C. Brown wrote:
> > 
> > > This is due to a change in the way gcc compiles code ... 3.4.0 may work,
> > > but later versions will cause functions to return prematurely (due to the 
> > > way
> > > qemu handles translated blocks). I suggested that a fix for this would be 
> > > to
> > > use function pointer calls instead of directly chaining machine code, but
> > > apparently this is too slow to make qemu usable.
> > 
> > The Forth way ;-)
> >...
> 
> How about instead post-processing the .s, replacing the rets with jumps
> to the end of the function?  Of course this part would be architecture
> dependant (different assembler syntax), but other parts of qemu
> are that as well, right?

This may be possible. I don't know if the change applies to gcc only, in which
case this is the best solution, or if it applies to gas as well, in which case
this would solve nothing.

Well, even if gas was changed, we could probably get around that by using a
newer gcc with an older gas as the backend ...

> 
>  Just a thought...
>       Juergen
> 
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.