On 11/13/07, Ralf Baechle <[EMAIL PROTECTED]> wrote:
> Old versions of glibc were probable the most notorious users of trampolines.
> Objective C also generates them. Since a cacheflush that is a syscall is
> required performance is less than great.
No Objective-C does not generate them. Objecti
David Daney wrote:
With the current kernel (2.6.23.1) in my R5000 based O2 it seems
impossible for GCC's exception unwinding machinery to unwind through
signal frames. The cause of the problems is the
ICACHE_REFILLS_WORKAROUND_WAR which puts the sigcontext at an almost
impossible to determine
On Tue, Nov 13, 2007 at 03:37:39PM +0100, Kevin D. Kissell wrote:
> True, though it should perhaps be noted that currently it's only on 4KSc/Sd
> systems (which I know you work on) where it's even possible for the stack
> *not* to have exec permissions, since the classical MIPS MMU gives
> execute
On Tue, Nov 13, 2007 at 03:22:33PM +0100, Franck Bui-Huu wrote:
> > > And the stack wouldn't need to have exec permission anymore.
> >
> > Oh?
> >
> > extern void frob(void (*)(void));
> >
> > int foo(void)
> > {
> > int x;
> >
> > void bar(void)
> > {
> > x
On Nov 13, 2007 3:37 PM, Kevin D. Kissell <[EMAIL PROTECTED]> wrote:
> Franck a dit:
> > > Another reason is to get rid of the classic trampoline the kernel installs
> > > on the stack. On some multiprocessor systems it requires a cacheflush
> > > operation to be performed on all processors which
Franck a dit:
> > Another reason is to get rid of the classic trampoline the kernel installs
> > on the stack. On some multiprocessor systems it requires a cacheflush
> > operation to be performed on all processors which is expensive. Having
> > the trampoline in a vDSO would solve that.
> >
>
>
On Nov 13, 2007 3:00 PM, Ralf Baechle <[EMAIL PROTECTED]> wrote:
>
> On Tue, Nov 13, 2007 at 02:14:58PM +0100, Franck Bui-Huu wrote:
>
> > > > David Daney writes:
> > > > > With the current kernel (2.6.23.1) in my R5000 based O2 it seems
> > > > > impossible for GCC's exception unwinding machiner
On Tue, Nov 13, 2007 at 02:14:58PM +0100, Franck Bui-Huu wrote:
> > > David Daney writes:
> > > > With the current kernel (2.6.23.1) in my R5000 based O2 it seems
> > > > impossible for GCC's exception unwinding machinery to unwind through
> > > > signal frames. The cause of the problems is th
On Nov 13, 2007 1:10 PM, Ralf Baechle <[EMAIL PROTECTED]> wrote:
>
> On Tue, Nov 13, 2007 at 11:48:53AM +, Andrew Haley wrote:
>
> > David Daney writes:
> > > With the current kernel (2.6.23.1) in my R5000 based O2 it seems
> > > impossible for GCC's exception unwinding machinery to unwind th
On Tue, Nov 13, 2007 at 11:48:53AM +, Andrew Haley wrote:
> David Daney writes:
> > With the current kernel (2.6.23.1) in my R5000 based O2 it seems
> > impossible for GCC's exception unwinding machinery to unwind through
> > signal frames. The cause of the problems is the
> > ICACHE_R
David Daney writes:
> With the current kernel (2.6.23.1) in my R5000 based O2 it seems
> impossible for GCC's exception unwinding machinery to unwind through
> signal frames. The cause of the problems is the
> ICACHE_REFILLS_WORKAROUND_WAR which puts the sigcontext at an almost
> impossib
With the current kernel (2.6.23.1) in my R5000 based O2 it seems
impossible for GCC's exception unwinding machinery to unwind through
signal frames. The cause of the problems is the
ICACHE_REFILLS_WORKAROUND_WAR which puts the sigcontext at an almost
impossible to determine offset from the sig
12 matches
Mail list logo