Re: i486 emu in mainline?

[Willy Tarreau <willy@w.ods.org>]

On Sun, May 23, 2004 at 07:08:36AM -0400, Alan Cox wrote:
> On Sun, May 23, 2004 at 10:29:12AM +0200, Willy Tarreau wrote:
> >     being emulated. I think it's already the case. He also said that I
> >     didn't take care of the segment selectors (such as SS) which some
> >     programs use perfectly legally (eg Wine). I don't know how to do
> >     that.
> 
> You have to parse all the valid header bytes (the opcode prefixes) that
> change segment, cause repeats and change sizes. DOSemu has a worked example
> of this particular set of horrors.

It's already what it does, but I don't use the segment base in the TSS nor
check the segment limit. It will take me quite some time to understand how
all this is implemented in the kernel and unfortunately I don't have such
time now.

> >   - why not include the CMOV emulation while we're at it ? There are so
> >     many people using VIA EDEN chips who think it's i686 compatible that
> >     they may get hit too. IIRC, the chip only executes CMOV on registers,
> >     but very slowly (a few tens of cycles), while register to memory
> >     accesses generate a trap.
> 
> gcc generates a lot of cmov on i686 so many that people I've talked with
> on the compiler side also feel cmov emulation isnt useful. Newer Eden btw
> has cmov.

agreed, but there are some programs which don't need speed at all, hence the
reason for my first implementation of cmov (which burnt about 400 cycles IIRC).

> > Other than that, I'm happy that someone found it useful, and happy too that
> > someone did the 2.6 port :-)
> 
> 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.

Thanks for your insights,
Willy