From owner-freebsd-threads@FreeBSD.ORG Mon Aug 11 09:11:10 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20D5837B401 for ; Mon, 11 Aug 2003 09:11:10 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FE6143FBF for ; Mon, 11 Aug 2003 09:11:09 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.233.125.100]) by attbi.com (rwcrmhc11) with ESMTP id <2003081116110801300i3vnfe>; Mon, 11 Aug 2003 16:11:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id JAA63157; Mon, 11 Aug 2003 09:11:06 -0700 (PDT) Date: Mon, 11 Aug 2003 09:11:05 -0700 (PDT) From: Julian Elischer To: Daniel Eischen In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: Marcel Moolenaar Subject: Re: KSE/ia64: NULL thread pointer in _thr_sig_add() X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2003 16:11:10 -0000 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" >