[Qemu-devel] Stuff.

[Qemu-devel] Stuff.

[David Woodhouse]

Has anyone considered the possibility of emulating libc, rather than
emulating system calls? That's what em86 used to do for emulating i386
code on Alpha -- rather than letting it run a 'real' non-native libc and
then emulating only syscalls. 

I appreciate that syscalls are a far more stable ABI to be emulating,
and there are far fewer structures to convert -- but wouldn't it be
faster to emulate the library itself? Especially if we can extend that
to emulate libX11 too :)

It's cute that I have i386 acroread running in a Mozilla window through
mozplugger. It'd be cuter if I could get Mozilla plugins running in the
_same_ process, rather than in a separate process. 


----

Also, why do we do what we do in linux-user/path.c? What does it give us
that couldn't be achieved by stat("$prefix/$filename") in a trivial
path() function? Other than taking for ever to start up when
/usr/gnemul/i386-linux is actually an nfs-mounted root file system from
elsewhere. (When I say forever I mean that literally. We keep following
symlinks recursively).

---- 

And is it possible to use the gdbstub when emulating userspace, rather
than a whole system? I see my ARM ld.so segfaulting, and I'd like to be
able to work out why. 

-- 
dwmw2

Re: [Qemu-devel] Stuff.

[Timo Savola]

> Has anyone considered the possibility of emulating libc, rather than
> emulating system calls? That's what em86 used to do for emulating i386
> code on Alpha -- rather than letting it run a 'real' non-native libc and
> then emulating only syscalls. 

I guess that wouldn't work very well with statically linked
applications.  Or when some other C library is used (uClibc).

Also, since the library and application code share global variables, it
would be next to impossible to know what data to convert to different
byte order and when.

> I appreciate that syscalls are a far more stable ABI to be emulating,
> and there are far fewer structures to convert -- but wouldn't it be
> faster to emulate the library itself? Especially if we can extend that
> to emulate libX11 too :)

I don't think the stability is so much of an issue than the size of the
interface.

Timo

Re: [Qemu-devel] Stuff.

[Fabrice Bellard]

David Woodhouse wrote:
> Has anyone considered the possibility of emulating libc, rather than
> emulating system calls? That's what em86 used to do for emulating i386
> code on Alpha -- rather than letting it run a 'real' non-native libc and
> then emulating only syscalls. 
> 
> I appreciate that syscalls are a far more stable ABI to be emulating,
> and there are far fewer structures to convert -- but wouldn't it be
> faster to emulate the library itself? Especially if we can extend that
> to emulate libX11 too :)

Emulating libc would be _very_ difficult (there are thousands of calls 
to convert). There were provisions in em86 to do that, but it was never 
really used. Moreover, I think the speed up would be small compared to 
the complexity of the task.

> It's cute that I have i386 acroread running in a Mozilla window through
> mozplugger. It'd be cuter if I could get Mozilla plugins running in the
> _same_ process, rather than in a separate process. 
> 
> 
> ----
> 
> Also, why do we do what we do in linux-user/path.c? What does it give us
> that couldn't be achieved by stat("$prefix/$filename") in a trivial
> path() function? Other than taking for ever to start up when
> /usr/gnemul/i386-linux is actually an nfs-mounted root file system from
> elsewhere. (When I say forever I mean that literally. We keep following
> symlinks recursively).

The goal was to avoid making too many syscalls.

Fabrice.

Re: [Qemu-devel] Stuff.

[Fabrice Bellard]

> And is it possible to use the gdbstub when emulating userspace, rather
> than a whole system? I see my ARM ld.so segfaulting, and I'd like to be
> able to work out why. 

Adding user space gdbstub support is possible. It is not on the top of 
my TODO list, so I won't do it in the near future.

Fabrice.

Re: [Qemu-devel] Stuff.

[Chris Emerson]

On Tue, May 04, 2004 at 10:31:09PM +0100, David Woodhouse wrote:
> Has anyone considered the possibility of emulating libc, rather than
> emulating system calls? That's what em86 used to do for emulating i386
> code on Alpha -- rather than letting it run a 'real' non-native libc
> and then emulating only syscalls. 

I did this with my own i386-on-ppc emulator.  It's a larger and less
well documented ABI, and can get quite messy.  OTOH, most of the
functions are easy and could be generated.

> I appreciate that syscalls are a far more stable ABI to be emulating,
> and there are far fewer structures to convert -- but wouldn't it be
> faster to emulate the library itself?

Probably, but I'd be interested to see some profiling data showing how
much time is actually spent emulating the libc etc. first.

> It's cute that I have i386 acroread running in a Mozilla window
> through mozplugger.

Ooh, I'll have to look into that.  Maybe I can have Flash on Linux/PPC
after all...

> It'd be cuter if I could get Mozilla plugins running in the _same_
> process, rather than in a separate process. 

You'd need to know the prototypes of all the functions you're calling
ahead of time, though...

Chris