Re: updating COMPAT_LINUX for linux 2.6.x support (take 2)

[Chuck Silvers <chuq%chuq.com@localhost>]

hi folks,

ok, more progress.  linux32 is working now and I fixed a few other bugs
along the way.

the updated diff is in
ftp://ftp.netbsd.org/pub/NetBSD/misc/chs/linux/diff.linux-nptl-take2.36


this patch includes:

 - apply joerg's patch for amd64 TLS, reworked a bit by me
   to support 32-bit processes as well.
 - update linux syscall table (for each platform).
 - support new-style (NPTL) linux pthreads on all platforms
   where linux supports it.  clone() with CLONE_THREAD uses
   1 process with many LWPs instead of separate processes.
 - update linux_release[] and linux32_release[] to "2.6.18". 
 - adjust placement of emul fork/exec/exit hooks as needed
   and adjust other emul code to match.
 - convert all struct emul definitions to use named initializers.
 - change the pid allocator to allow multiple pids to refer to the same proc.
 - remove a few fields from struct proc that are no longer needed.
 - fix amd64 CHECK_DEFERRED_SWITCH and DO_DEFERRED_SWITCH to
   use "cmpl" instead of "cmpq" to access a 32-bit field.
 - disable the non-functional "vdso" code in linux32/amd64,
   glibc works fine without it.
 - fix a race in the futex code where we could miss a wakeup after
   a requeue operation.
 - redo futex locking to be a little more efficient.


the LTP/posixtest pthread tests built as 32-bit now pass on amd64
as well as the 64-bit binaries do.  quite a few more tests pass now
than before, due to the futex fix.

there is one odd thing that I haven't been able to figure out:
I don't think we should need to reload %gs in INTRFASTEXIT on amd64
since swapgs will put back the user's gs.base value.
but if I take out the reload of %gs and run the 32-bit pthread tests,
within a few minutes the system will either reset or lock up.
anyone have any idea why this would be?  I'd appreciate it if
someone could look over the asm code changes in general.

oh, and if someone could test this on XEN that would be great too.

at this point the only changes that I'm planning to make are
combining some duplicated linux/i386 and linux32/amd64 code
and moving some stuff between files to better match the existing
code layout.  if no one sees anything else then I'll check this in
later this week.

-Chuck