KSE/ia64: NULL thread pointer in _thr_sig_add()
Daniel Eischen
eischen at vigrid.com
Mon Aug 11 08:24:04 PDT 2003
On Mon, 11 Aug 2003, Marcel Moolenaar wrote:
> 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.
OK, that's different than x86/amd64 then.
> > 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.
Try David's patch. It sets the current thread in the upcall
handler.
--
Dan Eischen
More information about the freebsd-threads
mailing list