Emmanuel Dreyfus wrote:
> Anyone knows the exact status of native threads on i386?

Well, apparently, some stuff works, some stuff not :)
Simple stuff like pieces of code testing clone(2) works, some
more complex things like RealPlayer fails sometimes. You might
want to check gnats for Linux-related PRs. All compat/linux PRs I'm aware of
are assigned to me, so you might use
	http://www.netbsd.org/Gnats/responsible/jdolecek.html
as a shortcut.

> message saying it listens on port 8080. The ktrace says it fails due to
> a spurious SIGSEGV. I'm working with Kevin B. Hendricks to find what's
> wrong, and that's not easy. Is someone has more information, please let
> me know.

I think stuff like this might be the result of using the stackgap
stuff. There is piece of memory shared between all threads of
process, which is used by compat code to fool "native" syscalls.
It seems to be possible that if one thread blocks in kernel, other
thread might do a syscall and overwrite that piece of memory.

I have been playing with changes to stop use the stackgap (for compat/linux,
at least), but got some problems I didn't have time to track them down,
so put this on hold.

> While we are there, what is the status of Linux gdb emulation on i386?
> Is it able to trace Linux processes? On PowerPC it's not, and I wonder

The ptrace(2) support on i386 is very crude. It doesn't really work quite
that well, was just able to give a partial traceback but not set a breakpoint
etc. I believe part of that might be that trapframe is different
on Linux.

Jaromir
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>      http://www.ics.muni.cz/~dolecek/
NetBSD - just plain best OS! -=*=- Got spare MCA cards or docs? Hand me them!