Date: Mon, 11 Aug 2003 08:05:41 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Daniel Eischen <eischen@vigrid.com> Cc: threads@freebsd.org Subject: Re: KSE/ia64: NULL thread pointer in _thr_sig_add() Message-ID: <20030811150541.GA566@dhcp42.pn.xcllnt.net> In-Reply-To: <Pine.GSO.4.10.10308111006460.9450-100000@pcnet5.pcnet.com> References: <20030811001030.GA27859@dhcp42.pn.xcllnt.net> <Pine.GSO.4.10.10308111006460.9450-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 11, 2003 at 10:22:50AM -0400, Daniel Eischen wrote:
> > The fault is given on the last instruction if the disassembly
> > given above (the thread pointer is r13):
> >
> > (gdb) info register r13
> > r13 0x0 0
> > (gdb) info register r14
> > r14 0xffffffffffffffe0 -32
>
> Right, that's what I was guessing.
>
> > Q: Shouldn't we call _tcb_set() somewhere in the code stream to make
> > sure we have a valid thread pointer?
>
> Once its set, it should always be set, right? The kernel doesn't
> change it, right? I think that's the idea anyways. If you look at
> the beginning of _thr_sched_multi(), we handle first time initialization:
The kernel creates a new context by virtue of the upcall. Since
we established earlier that the thread pointer itself is not part
of the context, you cannot assume that the thread pointer is not
destroyed.
> if ((curkse->k_flags & KF_INITIALIZED) == 0) {
> /* Setup this KSEs specific data. */
> _kcb_set(curkse->k_kcb);
>
> /* Set this before grabbing the context. */
> curkse->k_flags |= KF_INITIALIZED;
> }
>
> That should set it up so that we always have TP set to something
> (in this case, it's the fake tcb). But from then on, we rely
> on the kernel not to touch it. Are you sure the kernel doesn't
> destroy it somehow?
I'm positive that the kernel *does* clear _tp. It's by design.
--
Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030811150541.GA566>