lkml.org 
[lkml]   [2004]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: i486 emu in mainline?
On Sun, 2004-05-23 09:15:12 -0400, Alan Cox <alan@redhat.com>
wrote in message <20040523131512.GA25185@devserv.devel.redhat.com>:
> > > Is there a reason btw it can't be done with LD_PRELOAD ?
> >
> > Well, this is an interesting question. I don't know how to do it this way
> > (how can a program know exactly where the trap occured, etc... I don't know
> > how to program this). Other than that, LD_PRELOAD will not work against setuid
> > binaries. But if it does for the rest, I think it can become an elegant
> > approach.
>
> setuid binaries can still use /etc/ld.preload or whatever the file is called
> just not environment.

Being an old hardware user and tester (I still have a i386 and i486SLC
where I do testing on!), I strongly support the inclusion of the
emulator. I think that it should even be extended/fixed to catch the
remaining opcode(s).

> Someone actually did a libmmx long ago that used preload, hooked SIGILL
> and the signal handlers and used that to provide mmx on an mmx free cpu

There are some application that register signal handling functions IIRC
for SIGILL, SIGSEGV and the like to do internal error trapping on their
own (not only OOo comes to mind). These would probably be f*cked up if they
didn't call the LD_PRELOADed signal handler...

MfG, JBG

--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak!
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-03-22 14:03    [W:0.061 / U:0.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site