Date: Sat, 28 Jun 2003 12:20:03 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: threads@freebsd.org Subject: Re: KSE: fuword/suword bugs on ia64 Message-ID: <Pine.GSO.4.10.10306281150120.8518-100000@pcnet5.pcnet.com> In-Reply-To: <20030628153032.GA577@dhcp01.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10306281150120.8518-100000>