lkml.org 
[lkml]   [2003]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Emulating i486 on i386 (was: TSCs are a no-no on i386)
From
Date
On Thu, 2003-07-31 at 15:01, Jan-Benedict Glaw wrote:
> On Thu, 2003-07-31 14:14:48 +0200, Jan-Benedict Glaw <jbglaw@lug-owl.de>
> wrote in message <20030731121448.GW1873@lug-owl.de>:
> > On Thu, 2003-07-31 12:51:09 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk>
> > wrote in message <1059652268.16608.8.camel@dhcp22.swansea.linux.org.uk>:
> > > On Iau, 2003-07-31 at 12:38, Jan-Benedict Glaw wrote:
> > > > Thanks for that. In the meantime, I've started to give a try to the
> > > > userspace version (using a LD_PRELOAD lib). My current Problem:
> > > >
> > > > amtus:~/sigill_catcher# LD_PRELOAD=./libsigill.so ls
> > > > sigill.c:_init():69: sigill started, sigaction() = 0
> > > > build.sh intercept.h libsigill.so run.sh sigill.c sigill.o
> > > > amtus:~/sigill_catcher# LD_PRELOAD=./libsigill.so apt-get update
> > > > Illegal instruction
> > > >
> > > > See? It's loaded at the "ls" call, but it seems to be not loaded for
> > > > apt-get.
>
> So there we are. Thanks to someone who pointed me to LD_DEBUG et al., I
> see that my _init() is called too late:
>
> amtus:~/sigill_catcher# LD_DEBUG=all LD_VERBOSE=1
> LD_PRELOAD=./libsigill.so apt-get update 2> ld_infos
> Illegal instruction
> amtus:~/sigill_catcher# grep 'calling init' ld_infos
> 00691: calling init: /lib/libc.so.6
> 00691: calling init: /lib/libdl.so.2
> 00691: calling init: /lib/libgcc_s.so.1
> 00691: calling init: /lib/libm.so.6
> 00691: calling init: /usr/lib/libstdc++.so.5
>
> As I guessed, libstdc++5's _init() is called before mine (LD_PRELOADed)
> _init() function and thus, I cannot intercept this SIGILL, as it
> seems...
>

You could do what we do with our path sandbox - basically you
use a wrapper that setup the environment (prob not needed in
your case), and then spawn bash with our sandbox lib preloaded,
which then calls whatever should be 'path sandboxed'.

Should work with what you do as well, as bash/whatever do not use
c++ code, and when it execute the actual program, your lib should
have hooked into whatever that needs be.


Regards,

--
Martin Schlemmer


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:47    [from the cache]
©2003-2011 Jasper Spaans