Subject: COMPAT_NETBSD32 and Scheduler Activations status, one amd64 issue
To: None <tech-kern@netbsd.org>
From: Quentin Garnier <cube@cubidou.net>
List: tech-kern
Date: 01/03/2006 17:24:08
--e890kymSckUvwzhr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi folks,

First I'd like to let you know I was able to run a few of the regression
tests for libpthreads earlier, meaning that most of the work is at least
possible (I still have issues with locks apparently, but I haven't
looked at it closely).

That's all for the good news.  The bad news are first that the code is
rather ugly, notably because it makes the assumption that
sizeof(ucontext32_t) <=3D sizeof(ucontext_t) (yes, that's evil).  I think
there are ways to make all that part less hackish, probably introducing
some kind of a sa_emul structure that would make most of the work
opaque to the rest of the SA code.

As for MD code, a bit of it is needed, but not much.  Probably most of
it is already there for the other arch involved (I don't think sh5 is
really relevant right now, so it's only amd64 and sparc64).

I've only worked on amd64;  I might find a way to try stuff on sparc64
but I don't think it is time yet.  I do have an issue that is specific
to amd64, though.

The problem is that GDT entries are not ordered the same way in amd64
as they are in i386.  That means libpthread/i386's assumption that
GSEL(GUDATA, SEL_UPL) is 0x2b is invalid in a COMPAT_NETBSD32
environment (compare lib/libpthread/arch/i386/pthread_md.h and
sys/arch/amd64/include/segments.h).

To make things work on my system, I simply patched amd64's segments.h,
but by doing that, I broke the libpthread of my amd64 userland.

I see several ways of solving that issue:

1.  Teaching libpthread to ask the kernel to build a clean ucontext_t.
    That means COMPAT_NETBSD32 will only work with newer libpthread.

2.  Re-order GDT entries for amd64.
    That means amd64 userland will require a newer libpthread.

3.  Make libpthread use the current context to build a clean one.
    Same constraint as 1, and is it really safe?

4.  Switch the GDT for COMPAT_NETBSD32 processes?  Is it feasible?

Apart from case 4, support for older libraries will be broken one way
or another (making 1 the safer option).

Opinions?  I'll try cleaning up my current mess for that and post a
patch in a few days, maybe next week.

I'll post a patch for netbsd32 coredump issue, too (they're currently
broken).

--=20
Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
"When I find the controls, I'll go where I like, I'll know where I want
to be, but maybe for now I'll stay right here on a silent sea."
KT Tunstall, Silent Sea, Eye to the Telescope, 2004.

--e890kymSckUvwzhr
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQEVAwUBQ7qlKNgoQloHrPnoAQK4SAf/ekFtR1HEzRxfE6KKmVB6MxB/fPgzi03i
P5PViJ8nCpLDenmuFe3ottVnbIoqF89WOfOlo9yIbiZj4q5ati+qAz0JnhoTCopk
Kw2sw1eLZfOEe1d8htraXikQFa56uzefl5IyGHjrx5So1AWm539LWpCC8x2LE8gg
4RqZBILweQ4lGaRlcmH8pRZOVKnpnuRXhRd8bYJYRRACz+F001HIFkxHmaQ1lZZ9
L+89UfVDX7TDJPZ5pRtyEUnOi8P4GaBO73qEl6lrKpzEP9JyW2Y0bld7wiP42Aoj
oUBWzLscAJoaB9hMAVwLnG5X5e3e2tb1ospE+N3ehzgDo3LogiO1Hw==
=Hyxg
-----END PGP SIGNATURE-----

--e890kymSckUvwzhr--