Date: Mon, 11 Aug 2003 09:11:05 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Daniel Eischen <eischen@vigrid.com> Cc: Marcel Moolenaar <marcel@xcllnt.net> Subject: Re: KSE/ia64: NULL thread pointer in _thr_sig_add() Message-ID: <Pine.BSF.4.21.0308110909000.3704-100000@InterJet.elischer.org> In-Reply-To: <Pine.GSO.4.10.10308111122360.23323-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I think that david's patch is the correct answer.
an upcall has no thread so teh tp must be set to the dummy.
The only alternative would be to register a value for the TP that the
kernel could set when creating upcall context.
On Mon, 11 Aug 2003, Daniel Eischen wrote:
> 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
>
> _______________________________________________
> freebsd-threads@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-threads
> To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0308110909000.3704-100000>