From owner-freebsd-threads@FreeBSD.ORG Mon Aug 11 08:24:04 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 9F58737B401 for ; Mon, 11 Aug 2003 08:24:04 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E22C43FCB for ; Mon, 11 Aug 2003 08:24:03 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h7BFO2uN024575; Mon, 11 Aug 2003 11:24:02 -0400 (EDT) Date: Mon, 11 Aug 2003 11:24:02 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Marcel Moolenaar In-Reply-To: <20030811150541.GA566@dhcp42.pn.xcllnt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org 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 15:24:04 -0000 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