From owner-freebsd-current@FreeBSD.ORG Wed Dec 10 11:38:48 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC83316A4CE; Wed, 10 Dec 2003 11:38:47 -0800 (PST) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id B06B543D2A; Wed, 10 Dec 2003 11:38:43 -0800 (PST) (envelope-from craig@xfoil.gank.org) Received: from localhost (ion.gank.org [69.55.238.164]) by ion.gank.org (mail) with ESMTP id B17ED2B2FD; Wed, 10 Dec 2003 13:38:43 -0600 (CST) Received: from ion.gank.org ([69.55.238.164]) by localhost (ion.gank.org [69.55.238.164]) (amavisd-new, port 10024) with LMTP id 33591-06; Wed, 10 Dec 2003 13:38:42 -0600 (CST) Received: from owen1492.uf.corelab.com (pix.corelab.com [12.45.169.2]) by ion.gank.org (mail) with ESMTP id 82FFA2B2FC; Wed, 10 Dec 2003 13:38:41 -0600 (CST) From: Craig Boston To: "Jacques A. Vidrine" , Daniel Eischen Date: Wed, 10 Dec 2003 13:38:37 -0600 User-Agent: KMail/1.5.4 References: <200312092305.27056.craig@xfoil.gank.org> <20031210170815.GA77342@madman.celabo.org> In-Reply-To: <20031210170815.GA77342@madman.celabo.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200312101338.37175.craig@xfoil.gank.org> X-Virus-Scanned: by amavisd-new at gank.org cc: current@freebsd.org Subject: Re: nss and pthreads and wine, oh my! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2003 19:38:48 -0000 On Wednesday 10 December 2003 11:08 am, Jacques A. Vidrine wrote: > But, maybe I'm just misunderstanding you. I believe the thread > functions are `stubbed out' in the non-thread case? After more investigation, wine seems to be a special case. It's 'sort-of' threaded. It links against libc.so.5, but provides its own set of pthread functions that it uses internally (and are defined as strong aliases). The stub functions are getting called, but they're not pointing at stub_zero anymore. Actually, I can't figure out WHERE they're going... Here's a dump of the thread jump table right as wine starts up: (gdb) print __thr_jtable $1 = {{0x5c09d683 , 0x5c09d683 }, { 0x5c09d683 , 0x5c09d683 }, {0x5c09d683 , 0x5c09d683 }, {0x5c09d683 , 0x5c09d683 }, {0x5c09d683 , 0x5c09d683 }, {0x5c09d68d , 0x5c09d68d }, {0x5c09d683 , 0x5c09d683 }, {0x5c09d683 , 0x5c09d683 }, {0x5c09d6ad , 0x5c09d6ad }, {0x5c09d683 , 0x5c09d683 } , {0x5c09d697 , 0x5c09d697 }, {0x5c09d683 , 0x5c09d683 }, {0x5c09d683 , 0x5c09d683 }} Looks normal so far. Again in the middle of nsdispatch (right before the crash) (gdb) print __thr_jtable $3 = {{0x5ce1b33c, 0x5ce1b33c}, {0x5ce1aa3c, 0x5ce1aa3c}, {0x5ce1a944, 0x5ce1a944}, {0x5ce1b15c, 0x5ce1b15c}, {0x3c002298 <__pthread_cond_wait>, 0x5ce1aaad}, {0x5ce0db53, 0x5ce0db53}, {0x5ce0d6a4, 0x5ce0d6a4}, { 0x5ce0d7b6, 0x5ce0d7b6}, {0x5ce18c4c, 0x5ce18c4c}, {0x5ce13aa8, 0x5ce13aa8}, {0x5ce138aa, 0x5ce138aa}, {0x3c002003 <__pthread_mutex_lock>, 0x5ce1479f}, {0x3c002029 <__pthread_mutex_trylock>, 0x5ce140cd}, { 0x5ce1480a, 0x5ce1480a}, {0x5ce18a70, 0x5ce18a70}, {0x5ce18be4, 0x5ce18be4}, {0x5ce18b4b, 0x5ce18b4b}, {0x5ce134d8, 0x5ce134d8}, { 0x5ce119c8, 0x5ce119c8}, {0x5ce11a3c, 0x5ce11a3c}, {0x5ce11b42, 0x5ce11b42}, {0x5ce11c33, 0x5ce11c33}, {0x5ce11cf8, 0x5ce11cf8}, { 0x5ce11d9d, 0x5ce11d9d}, {0x5ce11e8f, 0x5ce11e8f}, {0x5ce11240, 0x5ce11240}, {0x5ce0da36, 0x5ce0da36}, {0x5ce0df30, 0x5ce0df30}} I know these offsets are meaningless, even between multiple sessions on my own machine, but: the 0x3c000000 functions are all part of wine's internal pthreads functions. That makes sense to me; they should override the stub functions in libc. But I haven't a clue what's at 0x5ce00000. Some shared library is getting loaded that has yet ANOTHER set of pthread functions. I don't think it's libc_r -- I have that built with debug symbols so they should be identified in that case... This is getting very complicated very fast. Is there any way in gdb to find out which shared libraries are loaded and what base address they got mapped to? Craig