KSE/ia64: NULL thread pointer in _thr_sig_add()

[Marcel Moolenaar]

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 at xcllnt.net