Re: GCC-3.4 reorders asm() with -O2

Re: GCC-3.4 reorders asm() with -O2

[Daniel Jacobowitz]

On Sun, Jan 25, 2004 at 04:47:58PM +0100, Andi Kleen wrote:
> On Sun, 25 Jan 2004 11:05:14 +0100
> Jan Hubicka <jh@suse.cz> wrote:
> 
> > > 
> > > > 
> > > > For x86 it does.  For MIPS I'm quite sure it doesn't - well, it will
> > > > compile, but not work.
> > > 
> > > but, unlike x86 this is hardly a surprise on a daily basis.
> > 
> > I think Andi has sollution that shall fix the other architectures in the
> > kernel too.
> 
> If it's the same problem that broke i386: Current bitkeeper should sort the exception tables
> and fix it. It's actually done with a patch from Paul Mackerras. Of course it could be a different
> issue too that's breaking MIPS.

It is.  Ralf already knows about the problem, I think - we leave
markers outside of functions which define an entry point, save some
additional registers to the stack, and try to fall through to the
following function.  If the function gets emitted elsewhere, obviously,
we've lost :)

[This is save_static_function...]

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: GCC-3.4 reorders asm() with -O2

[Ralf Baechle]

On Sun, Jan 25, 2004 at 12:03:51PM -0500, Daniel Jacobowitz wrote:

> It is.  Ralf already knows about the problem, I think - we leave
> markers outside of functions which define an entry point, save some
> additional registers to the stack, and try to fall through to the
> following function.  If the function gets emitted elsewhere, obviously,
> we've lost :)
> 
> [This is save_static_function...]

I only recently fixed the problem with the save_static() inline function
which of course was fragile, speculating on the compiler doing the
right thing ...  I'll cook up a fix ...

  Ralf

Re: GCC-3.4 reorders asm() with -O2

[Andi Kleen]

On Sun, 25 Jan 2004 19:26:43 +0100
Ralf Baechle <ralf@linux-mips.org> wrote:

> On Sun, Jan 25, 2004 at 12:03:51PM -0500, Daniel Jacobowitz wrote:
> 
> > It is.  Ralf already knows about the problem, I think - we leave
> > markers outside of functions which define an entry point, save some
> > additional registers to the stack, and try to fall through to the
> > following function.  If the function gets emitted elsewhere, obviously,
> > we've lost :)
> > 
> > [This is save_static_function...]
> 
> I only recently fixed the problem with the save_static() inline function
> which of course was fragile, speculating on the compiler doing the
> right thing ...  I'll cook up a fix ...

You can always use __attribute__((noinline))

-Andi

Re: GCC-3.4 reorders asm() with -O2

[Ralf Baechle]

On Sun, Jan 25, 2004 at 08:28:07PM +0100, Andi Kleen wrote:

> > > It is.  Ralf already knows about the problem, I think - we leave
> > > markers outside of functions which define an entry point, save some
> > > additional registers to the stack, and try to fall through to the
> > > following function.  If the function gets emitted elsewhere, obviously,
> > > we've lost :)
> > > 
> > > [This is save_static_function...]
> > 
> > I only recently fixed the problem with the save_static() inline function
> > which of course was fragile, speculating on the compiler doing the
> > right thing ...  I'll cook up a fix ...
> 
> You can always use __attribute__((noinline))

Not in this particular case.   save_static's purpose was saving all
caller saved registers into the stack so they can be accessed via the
usual struct pt_regs pointer and to make that work it to be inline before
any change of these registers.  That was a small optimization but it also
was fragile so I removed that.  save_static_function was meant to be
used immediately preceeding a syscall's C function and served the same
purpose.  As the implementation ``knew'' gcc wasn't going to move around
the code just falling though worked fine but again that was fragile.

  Ralf