From owner-freebsd-threads@FreeBSD.ORG Sat Jun 28 09:20:04 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEBC637B401 for ; Sat, 28 Jun 2003 09:20:04 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF5F44400F for ; Sat, 28 Jun 2003 09:20:03 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h5SGK3Xh012510; Sat, 28 Jun 2003 12:20:03 -0400 (EDT) Date: Sat, 28 Jun 2003 12:20:03 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Marcel Moolenaar In-Reply-To: <20030628153032.GA577@dhcp01.pn.xcllnt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: KSE: fuword/suword bugs on ia64 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2003 16:20:05 -0000 On Sat, 28 Jun 2003, Marcel Moolenaar wrote: > On Sat, Jun 28, 2003 at 10:06:02AM -0400, Daniel Eischen wrote: > > > > > > I've started runtime testing and ran into ILP32/LP64 bugs. Attached > > > a patch that solve the first problems without affecting i386. The > > > patch is intended to illustrate the problem more than it suggest a > > > solution. I'm more than happy to test alternative solutions. > > > Note that the use of uint32_t instead of unsigned int is mostly > > > to mirror the use of fuword32/suword32... > > > > I don't have any problem with the patch. Is there another > > solution you'd rather see, perhaps using 64bit values? > > I was thinking about using long. fuword/suword is defined in terms > of long, so technically it's a bug to have them operate on int. But > using long will yield 64-bit fields on 64-bit platforms, and it may > just be a waste of space. Although internal alignment and padding > may already take up as much space (tm_flags, km_version, km_flags > are examples of this). The mailboxes are not that big (with the exception of the thread mailbox due to ucontext), so a few extra bytes isn't going to hurt userland. Perhaps the copyin/copyout's in the kernel is what you're worried about? > I'm divided on the issue. I prefer using long for it being the best > native type, but don't like the immediate consequence of it being > too variable for use in interface types (take for example the 64-bit > long on i386 that bde is playing with). With the patch I favored > the fixed width property on uint32_t. You can use uint32_t for now as a quick fix. Perhaps we should restructure the mailboxen a bit as a longer term fix. David just added siginfo to the thread mailbox, so that's another MD structure. struct kse_thr_mailbox { /* u_long tm_version; */ /* ??? */ struct kse_thr_mailbox *tm_next; void *tm_udata; uint32_t tm_flags; uint32_t tm_uticks; uint32_t tm_sticks; uint32_t tm_spare[9]; siginfo_t tm_syncsig; ucontext_t tm_context; } This allows tm_context to change without affecting offsets to the other fields. The KSE mailbox has a version in it which can also identify what version of the thread mailbox, but it might make sense to stick a version field in the thread mailbox to make things easier. -- Dan Eischen