From owner-freebsd-amd64@FreeBSD.ORG Sun Jun 6 14:38:30 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FA4216A4CE; Sun, 6 Jun 2004 14:38:30 -0700 (PDT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id E286E43D1D; Sun, 6 Jun 2004 14:38:29 -0700 (PDT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 6EF55FD03A; Sun, 6 Jun 2004 14:38:29 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51960-04; Sun, 6 Jun 2004 14:38:29 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id DAB4DFD031; Sun, 6 Jun 2004 14:38:28 -0700 (PDT) From: Sean McNeil To: freebsd-amd64@freebsd.org, freebsd-threads@freebsd.org Content-Type: text/plain Message-Id: <1086557908.52631.11.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 06 Jun 2004 14:38:28 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com Subject: symbol binding on dlopen X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 21:38:30 -0000 I have been trying to formulate a reasonable explanation why I am seeing the following behavior: 1) start bash with nss_ldap. 2) nss_ldap pulls in libpthread.so.1 via. some non-direct dependency - libdb41.so.1. 3) Constructor is called for libpthread.so.1 that installs signal handler wrappers. 4) libreadline.so.4 uses sigaction, but it is not binding to the strong symbol of libpthread.so.1. It is still using the older one. Is this expected? Symbols will only be bound on the immediate dependencies of what is loaded by dlopen, or should all symbols within the closure be bound? Sean From owner-freebsd-amd64@FreeBSD.ORG Sun Jun 6 14:52:46 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0D9116A4CE; Sun, 6 Jun 2004 14:52:46 -0700 (PDT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBC2643D4C; Sun, 6 Jun 2004 14:52:46 -0700 (PDT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 97416FD03A; Sun, 6 Jun 2004 14:52:46 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52133-04; Sun, 6 Jun 2004 14:52:46 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id C7CD4FD031; Sun, 6 Jun 2004 14:52:45 -0700 (PDT) From: Sean McNeil To: freebsd-amd64@freebsd.org In-Reply-To: <1086557908.52631.11.camel@server.mcneil.com> References: <1086557908.52631.11.camel@server.mcneil.com> Content-Type: text/plain Message-Id: <1086558765.59346.3.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 06 Jun 2004 14:52:45 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-threads@freebsd.org Subject: Re: symbol binding on dlopen X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 21:52:47 -0000 On Sun, 2004-06-06 at 14:38, Sean McNeil wrote: > I have been trying to formulate a reasonable explanation why I am seeing > the following behavior: > > 1) start bash with nss_ldap. > 2) nss_ldap pulls in libpthread.so.1 via. some non-direct dependency - > libdb41.so.1. > 3) Constructor is called for libpthread.so.1 that installs signal > handler wrappers. > 4) libreadline.so.4 uses sigaction, but it is not binding to the strong > symbol of libpthread.so.1. It is still using the older one. > > Is this expected? Symbols will only be bound on the immediate > dependencies of what is loaded by dlopen, or should all symbols within > the closure be bound? (Answering my own question partly) nsdispatch calls dlopen with RTLD_LOCAL. If I understand correctly, that would mean this is expected and that libraries outside of the DAG wouldn't be effected (/lib/readline.so.4). From owner-freebsd-amd64@FreeBSD.ORG Sun Jun 6 16:28:45 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C89C16A4CE; Sun, 6 Jun 2004 16:28:44 -0700 (PDT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7645943D45; Sun, 6 Jun 2004 16:28:42 -0700 (PDT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 84714FD084; Sun, 6 Jun 2004 16:28:40 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00677-01; Sun, 6 Jun 2004 16:28:39 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 5B505FD052; Sun, 6 Jun 2004 16:28:39 -0700 (PDT) From: Sean McNeil To: freebsd-amd64@freebsd.org, freebsd-threads@freebsd.org Content-Type: text/plain Message-Id: <1086564518.1123.17.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 06 Jun 2004 16:28:39 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com Subject: more symbol binding problems X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 23:28:45 -0000 I have another one that I can't explain. apache2 and libphp4. The php4 shared library that is pulled into apache2 has the following (with pthread mapped to libc_r): /usr/local/libexec/apache2/libphp4.so: libcrypt.so.2 => /lib/libcrypt.so.2 (0x200aed000) libmcal.so => /usr/local/lib/libmcal.so (0x200c07000) libc-client4.so.8 => /usr/local/lib/libc-client4.so.8 (0x200d18000) libssl.so.3 => /usr/local/lib/libssl.so.3 (0x200ee2000) libcrypto.so.3 => /usr/local/lib/libcrypto.so.3 (0x20101c000) libexpat.so.5 => /usr/local/lib/libexpat.so.5 (0x201270000) libpq.so.3 => /usr/local/lib/libpq.so.3 (0x201393000) libmysqlclient.so.12 => /usr/local/lib/mysql/libmysqlclient.so.12 (0x2014b3000) libmhash.so.2 => /usr/local/lib/libmhash.so.2 (0x2015dc000) libmcrypt.so.8 => /usr/local/lib/libmcrypt.so.8 (0x2016f6000) libltdl.so.4 => /usr/local/lib/libltdl.so.4 (0x20182f000) libldap.so.2 => /usr/local/lib/libldap.so.2 (0x201937000) liblber.so.2 => /usr/local/lib/liblber.so.2 (0x201a6f000) libpam.so.2 => /usr/lib/libpam.so.2 (0x201b7d000) libintl.so.6 => /usr/local/lib/libintl.so.6 (0x201c85000) libz.so.2 => /lib/libz.so.2 (0x201d8f000) libm.so.2 => /lib/libm.so.2 (0x201e9e000) libxml2.so.5 => /usr/local/lib/libxml2.so.5 (0x201fbf000) libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x2021db000) libodbc.so.1 => /usr/local/lib/libodbc.so.1 (0x2023cb000) libssl.so.3 => /usr/lib/libssl.so.3 (0x202538000) libcrypto.so.3 => /lib/libcrypto.so.3 (0x202672000) libpthread.so.1 => /usr/lib/libc_r.so.5 (0x2027c5000) libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x2028f0000) libc.so.5 => /lib/libc.so.5 (0x20062a000) When I use the ldap account manager package (lam), it causes the httpd process to get stuck in a busy-loop eating 1/2 the cpu as: (gdb) bt #0 0x00000002014fcd4e in select () from /lib/libc.so.5 #1 0x0000000200c4532e in ldap_int_select (ld=0x8c8c00, timeout=0x0) at os-ip.c:733 #2 0x0000000200c34459 in wait4msg (ld=0x8c8c00, msgid=1, all=1, timeout=0x0, result=0x7fffffff9c38) at result.c:312 #3 0x0000000200c33fe7 in ldap_result (ld=0x8c8c00, msgid=1, all=1, timeout=0x0, result=0x7fffffff9c38) at result.c:113 #4 0x0000000200c376d4 in ldap_extended_operation_s (ld=0x8c8c00, reqoid=0x200c55134 "1.3.6.1.4.1.1466.20037", reqdata=0x0, sctrls=0x0, cctrls=0x0, retoidp=0x7fffffff9c90, retdatap=0x7fffffff9c98) at extended.c:138 #5 0x0000000200c4f606 in ldap_start_tls_s (ld=0x8c8c00, serverctrls=0x0, clientctrls=0x0) at tls.c:1725 #6 0x0000000203bf7a62 in ?? () from /usr/local/libexec/apache2/libphp4.so #7 0x0000000203cbfcd3 in ?? () from /usr/local/libexec/apache2/libphp4.so #8 0x0000000203cbfec9 in ?? () from /usr/local/libexec/apache2/libphp4.so #9 0x0000000203cb2a8a in ?? () from /usr/local/libexec/apache2/libphp4.so #10 0x0000000203c8cbee in ?? () from /usr/local/libexec/apache2/libphp4.so #11 0x0000000203cc4ca5 in ?? () from /usr/local/libexec/apache2/libphp4.so #12 0x00000000004222ea in ap_run_handler (r=0x7ba090) at config.c:151 #13 0x0000000000422860 in ap_invoke_handler (r=0x7ba090) at config.c:358 #14 0x000000000041f973 in ap_process_request (r=0x7ba090) at http_request.c:246 #15 0x000000000041b5bc in ap_process_http_connection (c=0x7b21b0) I do not understand why it is calling select in lib.so.5. Shouldn't it have called the one in libc_r? With GLOBAL or LOCAL DAG this should have been resolved via the weak symbol to __select, no? The interesting thing here is that if I use libpthread for apache then there are no problems. Maybe not all that suprising, though, as there is no real difference in the select with libpthread whereas libc_r has a much more complex implementation. Cheers, Sean From owner-freebsd-amd64@FreeBSD.ORG Sun Jun 6 17:25:47 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C81C416A4CE; Sun, 6 Jun 2004 17:25:47 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81B8143D1F; Sun, 6 Jun 2004 17:25:47 -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.10/8.12.1) with ESMTP id i570PktD023192; Sun, 6 Jun 2004 20:25:46 -0400 (EDT) Date: Sun, 6 Jun 2004 20:25:46 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086564518.1123.17.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 00:25:47 -0000 On Sun, 6 Jun 2004, Sean McNeil wrote: > I have another one that I can't explain. apache2 and libphp4. > > The php4 shared library that is pulled into apache2 has the following > (with pthread mapped to libc_r): > > /usr/local/libexec/apache2/libphp4.so: [ ... ] > libssl.so.3 => /usr/lib/libssl.so.3 (0x202538000) > libcrypto.so.3 => /lib/libcrypto.so.3 (0x202672000) > libpthread.so.1 => /usr/lib/libc_r.so.5 (0x2027c5000) > libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x2028f0000) > libc.so.5 => /lib/libc.so.5 (0x20062a000) > > When I use the ldap account manager package (lam), it causes the httpd > process to get stuck in a busy-loop eating 1/2 the cpu as: > > (gdb) bt > #0 0x00000002014fcd4e in select () from /lib/libc.so.5 > #1 0x0000000200c4532e in ldap_int_select (ld=0x8c8c00, timeout=0x0) > at os-ip.c:733 > > I do not understand why it is calling select in lib.so.5. Shouldn't it > have called the one in libc_r? With GLOBAL or LOCAL DAG this should > have been resolved via the weak symbol to __select, no? Yes, it shouldn't be using select() from libc; select() should be resolved to _select() in libc_r (which calls __sys_poll() in libc). > The interesting thing here is that if I use libpthread for apache then > there are no problems. Maybe not all that suprising, though, as there > is no real difference in the select with libpthread whereas libc_r has a > much more complex implementation. Sounds like the linker isn't doing the right thing. -- Dan Eischen From owner-freebsd-amd64@FreeBSD.ORG Sun Jun 6 17:44:13 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92D1316A4CE; Sun, 6 Jun 2004 17:44:13 -0700 (PDT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 689A543D48; Sun, 6 Jun 2004 17:44:13 -0700 (PDT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id CB594FD020; Sun, 6 Jun 2004 17:44:12 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00678-03; Sun, 6 Jun 2004 17:44:12 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 9A0D3FD01A; Sun, 6 Jun 2004 17:44:11 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1086569050.66929.2.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 06 Jun 2004 17:44:11 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 00:44:13 -0000 On Sun, 2004-06-06 at 17:25, Daniel Eischen wrote: > On Sun, 6 Jun 2004, Sean McNeil wrote: > > > I have another one that I can't explain. apache2 and libphp4. > > > > The php4 shared library that is pulled into apache2 has the following > > (with pthread mapped to libc_r): > > > > /usr/local/libexec/apache2/libphp4.so: > [ ... ] > > libssl.so.3 => /usr/lib/libssl.so.3 (0x202538000) > > libcrypto.so.3 => /lib/libcrypto.so.3 (0x202672000) > > libpthread.so.1 => /usr/lib/libc_r.so.5 (0x2027c5000) > > libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x2028f0000) > > libc.so.5 => /lib/libc.so.5 (0x20062a000) > > > > When I use the ldap account manager package (lam), it causes the httpd > > process to get stuck in a busy-loop eating 1/2 the cpu as: > > > > (gdb) bt > > #0 0x00000002014fcd4e in select () from /lib/libc.so.5 > > #1 0x0000000200c4532e in ldap_int_select (ld=0x8c8c00, timeout=0x0) > > at os-ip.c:733 > > > > I do not understand why it is calling select in lib.so.5. Shouldn't it > > have called the one in libc_r? With GLOBAL or LOCAL DAG this should > > have been resolved via the weak symbol to __select, no? > > Yes, it shouldn't be using select() from libc; select() should be > resolved to _select() in libc_r (which calls __sys_poll() in libc). > > > The interesting thing here is that if I use libpthread for apache then > > there are no problems. Maybe not all that suprising, though, as there > > is no real difference in the select with libpthread whereas libc_r has a > > much more complex implementation. > > Sounds like the linker isn't doing the right thing. Would you think it is the linker, or rtld? Any ideas where I should start? I was going to look through rtld but I will focus on ld if you think that is where the problem is. From owner-freebsd-amd64@FreeBSD.ORG Mon Jun 7 03:52:56 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C7DF016A4CE; Mon, 7 Jun 2004 03:52:56 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34C0443D1F; Sun, 6 Jun 2004 20:52:56 -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.10/8.12.1) with ESMTP id i573qrtD010682; Sun, 6 Jun 2004 23:52:55 -0400 (EDT) Date: Sun, 6 Jun 2004 23:52:53 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086569050.66929.2.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 03:52:56 -0000 On Sun, 6 Jun 2004, Sean McNeil wrote: > On Sun, 2004-06-06 at 17:25, Daniel Eischen wrote: > > On Sun, 6 Jun 2004, Sean McNeil wrote: > > > > > I do not understand why it is calling select in lib.so.5. Shouldn't it > > > have called the one in libc_r? With GLOBAL or LOCAL DAG this should > > > have been resolved via the weak symbol to __select, no? > > > > Yes, it shouldn't be using select() from libc; select() should be > > resolved to _select() in libc_r (which calls __sys_poll() in libc). > > > > > The interesting thing here is that if I use libpthread for apache then > > > there are no problems. Maybe not all that suprising, though, as there > > > is no real difference in the select with libpthread whereas libc_r has a > > > much more complex implementation. > > > > Sounds like the linker isn't doing the right thing. > > Would you think it is the linker, or rtld? Any ideas where I should > start? I was going to look through rtld but I will focus on ld if you > think that is where the problem is. I meant the run-time linker (rtld). -- Dan Eischen From owner-freebsd-amd64@FreeBSD.ORG Mon Jun 7 03:56:59 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6ABF516A4CE; Mon, 7 Jun 2004 03:56:59 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 241B843D45; Sun, 6 Jun 2004 20:56:59 -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.10/8.12.1) with ESMTP id i573uwtD011570; Sun, 6 Jun 2004 23:56:58 -0400 (EDT) Date: Sun, 6 Jun 2004 23:56:58 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086569050.66929.2.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 03:56:59 -0000 On Sun, 6 Jun 2004, Sean McNeil wrote: > On Sun, 2004-06-06 at 17:25, Daniel Eischen wrote: > > On Sun, 6 Jun 2004, Sean McNeil wrote: > > > > > I have another one that I can't explain. apache2 and libphp4. > > > > > > The php4 shared library that is pulled into apache2 has the following > > > (with pthread mapped to libc_r): > > > > > > /usr/local/libexec/apache2/libphp4.so: > > [ ... ] > > > libssl.so.3 => /usr/lib/libssl.so.3 (0x202538000) > > > libcrypto.so.3 => /lib/libcrypto.so.3 (0x202672000) > > > libpthread.so.1 => /usr/lib/libc_r.so.5 (0x2027c5000) > > > libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x2028f0000) > > > libc.so.5 => /lib/libc.so.5 (0x20062a000) You really want to look at the executable (httpd?) too. What does 'ldd' on it show? -- Dan Eischen From owner-freebsd-amd64@FreeBSD.ORG Mon Jun 7 04:06:30 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BFD416A4CE; Mon, 7 Jun 2004 04:06:30 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DA0043D4C; Sun, 6 Jun 2004 21:06:28 -0700 (PDT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 9A7C2FD01A; Sun, 6 Jun 2004 21:06:27 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59142-03; Sun, 6 Jun 2004 21:06:27 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 1E534FD012; Sun, 6 Jun 2004 21:06:27 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1086581186.59212.12.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 06 Jun 2004 21:06:27 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 04:06:30 -0000 On Sun, 2004-06-06 at 20:56, Daniel Eischen wrote: > On Sun, 6 Jun 2004, Sean McNeil wrote: > > > On Sun, 2004-06-06 at 17:25, Daniel Eischen wrote: > > > On Sun, 6 Jun 2004, Sean McNeil wrote: > > > > > > > I have another one that I can't explain. apache2 and libphp4. > > > > > > > > The php4 shared library that is pulled into apache2 has the following > > > > (with pthread mapped to libc_r): > > > > > > > > /usr/local/libexec/apache2/libphp4.so: > > > [ ... ] > > > > libssl.so.3 => /usr/lib/libssl.so.3 (0x202538000) > > > > libcrypto.so.3 => /lib/libcrypto.so.3 (0x202672000) > > > > libpthread.so.1 => /usr/lib/libc_r.so.5 (0x2027c5000) > > > > libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x2028f0000) > > > > libc.so.5 => /lib/libc.so.5 (0x20062a000) > > You really want to look at the executable (httpd?) too. What > does 'ldd' on it show? Hmmm... /usr/local/sbin/httpd: libz.so.2 => /lib/libz.so.2 (0x200675000) libssl.so.3 => /usr/local/lib/libssl.so.3 (0x200784000) libcrypto.so.3 => /usr/local/lib/libcrypto.so.3 (0x2008be000) libaprutil-0.so.9 => /usr/local/lib/apache2/libaprutil-0.so.9 (0x200b12000) libldap.so.2 => /usr/local/lib/libldap.so.2 (0x200c28000) liblber.so.2 => /usr/local/lib/liblber.so.2 (0x200d60000) libdb41.so.1 => /usr/local/lib/libdb41.so.1 (0x200e6e000) libexpat.so.5 => /usr/local/lib/libexpat.so.5 (0x20102b000) libapr-0.so.9 => /usr/local/lib/apache2/libapr-0.so.9 (0x20114e000) libm.so.2 => /lib/libm.so.2 (0x201270000) libcrypt.so.2 => /lib/libcrypt.so.2 (0x201391000) libc.so.5 => /lib/libc.so.5 (0x2014ab000) libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x2016a9000) So it looks like it is pulling in the ldap library without pthreads/libc_r first. So I think what is happening is that the symbols resolved with ldap aren't updated when it is part of the DAG of php4. Not sure why these would get resolved so early. I should think they are lazy and happen a lot later. But perhaps that is the bug? Are lazy resolutions failing to take into account the threading library needs from dlopen'ing php4? From owner-freebsd-amd64@FreeBSD.ORG Mon Jun 7 04:37:44 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 448B116A4E2; Mon, 7 Jun 2004 04:37:44 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4E1D43D39; Mon, 7 Jun 2004 04:37:43 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i574bhtD020478; Mon, 7 Jun 2004 00:37:43 -0400 (EDT) Date: Mon, 7 Jun 2004 00:37:43 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086581186.59212.12.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 04:37:44 -0000 On Sun, 6 Jun 2004, Sean McNeil wrote: > On Sun, 2004-06-06 at 20:56, Daniel Eischen wrote: > > You really want to look at the executable (httpd?) too. What > > does 'ldd' on it show? > > Hmmm... > > /usr/local/sbin/httpd: > libz.so.2 => /lib/libz.so.2 (0x200675000) > libssl.so.3 => /usr/local/lib/libssl.so.3 (0x200784000) > libcrypto.so.3 => /usr/local/lib/libcrypto.so.3 (0x2008be000) > libaprutil-0.so.9 => /usr/local/lib/apache2/libaprutil-0.so.9 > (0x200b12000) > libldap.so.2 => /usr/local/lib/libldap.so.2 (0x200c28000) > liblber.so.2 => /usr/local/lib/liblber.so.2 (0x200d60000) > libdb41.so.1 => /usr/local/lib/libdb41.so.1 (0x200e6e000) > libexpat.so.5 => /usr/local/lib/libexpat.so.5 (0x20102b000) > libapr-0.so.9 => /usr/local/lib/apache2/libapr-0.so.9 > (0x20114e000) > libm.so.2 => /lib/libm.so.2 (0x201270000) > libcrypt.so.2 => /lib/libcrypt.so.2 (0x201391000) > libc.so.5 => /lib/libc.so.5 (0x2014ab000) > libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x2016a9000) > > So it looks like it is pulling in the ldap library without > pthreads/libc_r first. So I think what is happening is that the symbols > resolved with ldap aren't updated when it is part of the DAG of php4. > Not sure why these would get resolved so early. I should think they are > lazy and happen a lot later. But perhaps that is the bug? Are lazy > resolutions failing to take into account the threading library needs > from dlopen'ing php4? Libc is the second library on the list, so any attempt to dlopen() a library that needs libc_r (or even libpthread) isn't going to work correctly. I think basically all your problems are the result of things being linked (ld) improperly. If the executable is going to dlopen() a library that requires the threads library, then the executable must explicitly link to the threads libary. I said before, if you set CFLAGS=-pthread, it will avoid linking to libpthread when building shared libraries. -- Dan Eischen From owner-freebsd-amd64@FreeBSD.ORG Mon Jun 7 04:59:35 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FC4E16A4CE; Mon, 7 Jun 2004 04:59:35 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4157F43D46; Mon, 7 Jun 2004 04:59:35 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 98B6AFD03B; Sun, 6 Jun 2004 21:59:30 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59128-07; Sun, 6 Jun 2004 21:59:30 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id DE74BFD020; Sun, 6 Jun 2004 21:59:29 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1086584369.7335.11.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 06 Jun 2004 21:59:29 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 04:59:35 -0000 On Sun, 2004-06-06 at 21:37, Daniel Eischen wrote: > On Sun, 6 Jun 2004, Sean McNeil wrote: > > > On Sun, 2004-06-06 at 20:56, Daniel Eischen wrote: > > > You really want to look at the executable (httpd?) too. What > > > does 'ldd' on it show? > > > > Hmmm... > > > > /usr/local/sbin/httpd: > > libz.so.2 => /lib/libz.so.2 (0x200675000) > > libssl.so.3 => /usr/local/lib/libssl.so.3 (0x200784000) > > libcrypto.so.3 => /usr/local/lib/libcrypto.so.3 (0x2008be000) > > libaprutil-0.so.9 => /usr/local/lib/apache2/libaprutil-0.so.9 > > (0x200b12000) > > libldap.so.2 => /usr/local/lib/libldap.so.2 (0x200c28000) > > liblber.so.2 => /usr/local/lib/liblber.so.2 (0x200d60000) > > libdb41.so.1 => /usr/local/lib/libdb41.so.1 (0x200e6e000) > > libexpat.so.5 => /usr/local/lib/libexpat.so.5 (0x20102b000) > > libapr-0.so.9 => /usr/local/lib/apache2/libapr-0.so.9 > > (0x20114e000) > > libm.so.2 => /lib/libm.so.2 (0x201270000) > > libcrypt.so.2 => /lib/libcrypt.so.2 (0x201391000) > > libc.so.5 => /lib/libc.so.5 (0x2014ab000) > > libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x2016a9000) > > > > So it looks like it is pulling in the ldap library without > > pthreads/libc_r first. So I think what is happening is that the symbols > > resolved with ldap aren't updated when it is part of the DAG of php4. > > Not sure why these would get resolved so early. I should think they are > > lazy and happen a lot later. But perhaps that is the bug? Are lazy > > resolutions failing to take into account the threading library needs > > from dlopen'ing php4? > > Libc is the second library on the list, so any attempt to dlopen() > a library that needs libc_r (or even libpthread) isn't going to > work correctly. > > I think basically all your problems are the result of things > being linked (ld) improperly. If the executable is going to > dlopen() a library that requires the threads library, then > the executable must explicitly link to the threads libary. > I said before, if you set CFLAGS=-pthread, it will avoid > linking to libpthread when building shared libraries. That is very interesting. This works perfectly for i386 and always has. There is a fundamental difference here that is going to cause all sorts of issues with ports and programs. Essentially, there is no reason why this should not work. It works for Linux, it works for FreeBSD/x86, why not FreeBSD/amd64? You may be 10000% correct in principle, I don't know. I personally think that this should not be the case. Anyone should be able to create loadable extensions to a program that may do threading of some sort and not require the starting application to be linked with the thread library. Principle is all well and good, but we why enforce something that doesn't need to be? Why can't freebsd/amd64 behave nice like freebsd/i386. Let me make reiterate.... I am using a system that I converted from i386 to amd64. Everything (all the ports) were working without any problems whatsoever. These are the same exact ports that I convert over to amd64. If it is not legal to do things like this then why do these exact same ports work perfectly fine with freebsd/i386? Your analysis and assistance with this has been invaluable so far, but I don't want this to just be dismissed because in principle it doesn't need to be supported. IMHO, amd64 should work just like i386. Since it works with i386, shouldn't we make it work for amd64? Sean From owner-freebsd-amd64@FreeBSD.ORG Mon Jun 7 05:30:55 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 492FB16A4CE; Mon, 7 Jun 2004 05:30:55 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF48B43D2D; Mon, 7 Jun 2004 05:30:54 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i575UrtD001611; Mon, 7 Jun 2004 01:30:53 -0400 (EDT) Date: Mon, 7 Jun 2004 01:30:53 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086584369.7335.11.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 05:30:55 -0000 On Sun, 6 Jun 2004, Sean McNeil wrote: > On Sun, 2004-06-06 at 21:37, Daniel Eischen wrote: > > > > Libc is the second library on the list, so any attempt to dlopen() > > a library that needs libc_r (or even libpthread) isn't going to > > work correctly. > > > > I think basically all your problems are the result of things > > being linked (ld) improperly. If the executable is going to > > dlopen() a library that requires the threads library, then > > the executable must explicitly link to the threads libary. > > I said before, if you set CFLAGS=-pthread, it will avoid > > linking to libpthread when building shared libraries. > > That is very interesting. This works perfectly for i386 and always > has. There is a fundamental difference here that is going to cause all > sorts of issues with ports and programs. Essentially, there is no > reason why this should not work. It works for Linux, it works for > FreeBSD/x86, why not FreeBSD/amd64? Show me the same exact shared library dependencies under x86. > You may be 10000% correct in principle, I don't know. I personally > think that this should not be the case. Anyone should be able to create > loadable extensions to a program that may do threading of some sort and > not require the starting application to be linked with the thread > library. Principle is all well and good, but we why enforce something > that doesn't need to be? Why can't freebsd/amd64 behave nice like > freebsd/i386. It doesn't work under i386 either. Remember the nss_ldap problem? That was exactly the same and on i386. > Let me make reiterate.... I am using a system that I converted from > i386 to amd64. Everything (all the ports) were working without any > problems whatsoever. These are the same exact ports that I convert over > to amd64. If it is not legal to do things like this then why do these > exact same ports work perfectly fine with freebsd/i386? > > Your analysis and assistance with this has been invaluable so far, but I > don't want this to just be dismissed because in principle it doesn't > need to be supported. IMHO, amd64 should work just like i386. Since it > works with i386, shouldn't we make it work for amd64? There is no difference. It isn't going to work on i386 either. Once you load the threads library, the libc locking functions will be overloaded with the locking functions in libpthread. When libpthread is unloaded, libc locking functions still point to the now non-existent library. If something tries to use a lock, fall down go boom. There's also the problem of overloaded functions and cancellation points. These won't work correctly because of ordering. It's like trying to use '-lc -lpthread' to link an application. That isn't going to work; you need '-lpthread -lc'. There are two reasons for a library to use the threads library. a) It uses threading functions for thread safety; or b) It creates threads behind the scenes (for instance if there were a libaio). For a), it needn't link to the threads library because all the necessary locking functions are in libc. If an application is threaded, then the threads library will be pulled in (along with the locking functions) because the _application_ will be linked to the threads library. For b), we mandate that the application always be linked with the threads library because the library needs threads. This should be solved by fixing the ports appropriately. For a), it can be done by using PTHREAD_LIBS=-pthread. -- Dan Eischen From owner-freebsd-amd64@FreeBSD.ORG Mon Jun 7 09:38:18 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B42A316A516 for ; Mon, 7 Jun 2004 09:38:18 +0000 (GMT) Received: from TRANG.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F45543D39 for ; Mon, 7 Jun 2004 09:38:18 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by TRANG.nuxi.com (8.12.11/8.12.10) with ESMTP id i579c6m4029638; Mon, 7 Jun 2004 02:38:06 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.11/8.12.11/Submit) id i579c6Te029637; Mon, 7 Jun 2004 02:38:06 -0700 (PDT) (envelope-from obrien) Date: Mon, 7 Jun 2004 02:38:05 -0700 From: "David O'Brien" To: Sean McNeil Message-ID: <20040607093805.GA29340@dragon.nuxi.com> References: <1086390190.69872.2.camel@server.mcneil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1086390190.69872.2.camel@server.mcneil.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: freebsd-amd64@freebsd.org Subject: Re: debugger that works? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 09:38:18 -0000 On Fri, Jun 04, 2004 at 04:03:10PM -0700, Sean McNeil wrote: > Anyone have one? > > I've built a debugger from cvs as /usr/ports/devel/gdb6 doesn't point to > a valid source. I get all kinds of junk in backtraces and attaching to > a process doesn't work. Please send me a core file + binary; or post more information about the "all kinds of junk in backtraces". gdb6 works for me here [in userland]. -- -- David (obrien@FreeBSD.org) From owner-freebsd-amd64@FreeBSD.ORG Mon Jun 7 10:15:01 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7353D16A4CE; Mon, 7 Jun 2004 10:15:01 +0000 (GMT) Received: from freebee.digiware.nl (dsl390.iae.nl [212.61.63.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A0D343D1F; Mon, 7 Jun 2004 10:15:00 +0000 (GMT) (envelope-from wjw@withagen.nl) Received: from dual (dual [212.61.27.71]) by freebee.digiware.nl (8.12.10/8.12.10) with SMTP id i57A9d67058622; Mon, 7 Jun 2004 12:09:40 +0200 (CEST) (envelope-from wjw@withagen.nl) Message-ID: <079101c44c77$962bf960$471b3dd4@dual> From: "Willem Jan Withagen" To: , "Sean McNeil" References: <1086390190.69872.2.camel@server.mcneil.com> <20040607093805.GA29340@dragon.nuxi.com> Date: Mon, 7 Jun 2004 12:09:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 cc: freebsd-amd64@freebsd.org Subject: Re: debugger that works? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 10:15:01 -0000 > On Fri, Jun 04, 2004 at 04:03:10PM -0700, Sean McNeil wrote: > > Anyone have one? > > > > I've built a debugger from cvs as /usr/ports/devel/gdb6 doesn't point to > > a valid source. I get all kinds of junk in backtraces and attaching to > > a process doesn't work. > > Please send me a core file + binary; or post more information about the > "all kinds of junk in backtraces". gdb6 works for me here [in userland]. gdb6 is been my friend since may 17th. xxgdb does not work, but I have not looked into it as to why. backtrace was a great help to get the bugs I was searching for --WjW From owner-freebsd-amd64@FreeBSD.ORG Mon Jun 7 10:18:32 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D74416A4CE; Mon, 7 Jun 2004 10:18:32 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4890F43D5D; Mon, 7 Jun 2004 10:18:30 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id CBA1DFD03B; Mon, 7 Jun 2004 03:18:17 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08046-07; Mon, 7 Jun 2004 03:18:17 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 22129FD020; Mon, 7 Jun 2004 03:18:17 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1086603496.7335.29.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 07 Jun 2004 03:18:17 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 10:18:32 -0000 On Sun, 2004-06-06 at 22:30, Daniel Eischen wrote: > On Sun, 6 Jun 2004, Sean McNeil wrote: > > > On Sun, 2004-06-06 at 21:37, Daniel Eischen wrote: > > > > > > Libc is the second library on the list, so any attempt to dlopen() > > > a library that needs libc_r (or even libpthread) isn't going to > > > work correctly. > > > > > > I think basically all your problems are the result of things > > > being linked (ld) improperly. If the executable is going to > > > dlopen() a library that requires the threads library, then > > > the executable must explicitly link to the threads libary. > > > I said before, if you set CFLAGS=-pthread, it will avoid > > > linking to libpthread when building shared libraries. > > > > That is very interesting. This works perfectly for i386 and always > > has. There is a fundamental difference here that is going to cause all > > sorts of issues with ports and programs. Essentially, there is no > > reason why this should not work. It works for Linux, it works for > > FreeBSD/x86, why not FreeBSD/amd64? > > Show me the same exact shared library dependencies under x86. I'm sorry, but I have rebuilt everything on this machine from i386 to amd64 so I do not have the older binaries to show the same dependency. Unless something odd happened between the following: 1) working i386. 2) build world build/install kernel with a target arch amd64 3) cp ld-elf.so.1 to ld-elf32.so.1, reboot, install world 4) portupgrade -af then the dependencies should be identical between i386 and amd64. > > You may be 10000% correct in principle, I don't know. I personally > > think that this should not be the case. Anyone should be able to create > > loadable extensions to a program that may do threading of some sort and > > not require the starting application to be linked with the thread > > library. Principle is all well and good, but we why enforce something > > that doesn't need to be? Why can't freebsd/amd64 behave nice like > > freebsd/i386. > > It doesn't work under i386 either. Remember the nss_ldap > problem? That was exactly the same and on i386. There is no nss_ldap problem. nss_ldap worked perfectly on i386. It causes issues on amd64 because of a problem in threads. > > Let me make reiterate.... I am using a system that I converted from > > i386 to amd64. Everything (all the ports) were working without any > > problems whatsoever. These are the same exact ports that I convert over > > to amd64. If it is not legal to do things like this then why do these > > exact same ports work perfectly fine with freebsd/i386? > > > > Your analysis and assistance with this has been invaluable so far, but I > > don't want this to just be dismissed because in principle it doesn't > > need to be supported. IMHO, amd64 should work just like i386. Since it > > works with i386, shouldn't we make it work for amd64? > > There is no difference. It isn't going to work on i386 either. > Once you load the threads library, the libc locking functions > will be overloaded with the locking functions in libpthread. > When libpthread is unloaded, libc locking functions still point > to the now non-existent library. If something tries to use > a lock, fall down go boom. It worked on i386. None of the cases mentioned before unload the thread library until an atexit. > There's also the problem of overloaded functions and cancellation > points. These won't work correctly because of ordering. It's > like trying to use '-lc -lpthread' to link an application. > That isn't going to work; you need '-lpthread -lc'. As far as I know, this works. At least for Linux and it should for FreeBSD. The ordering doesn't matter because the overloaded routines are actually weak references in libc and strong references in pthread. So pthread symbols win. > There are two reasons for a library to use the threads library. > > a) It uses threading functions for thread safety; or > b) It creates threads behind the scenes (for instance > if there were a libaio). > > For a), it needn't link to the threads library because all > the necessary locking functions are in libc. If an application > is threaded, then the threads library will be pulled in (along > with the locking functions) because the _application_ will > be linked to the threads library. For b), we mandate that > the application always be linked with the threads library > because the library needs threads. So I think we agree that thread-safe libraries should not link with -lpthread if they do not call thread-specific routines. > This should be solved by fixing the ports appropriately. > For a), it can be done by using PTHREAD_LIBS=-pthread. From owner-freebsd-amd64@FreeBSD.ORG Mon Jun 7 11:01:58 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C4F0516A50E for ; Mon, 7 Jun 2004 11:01:58 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1DF643D1D for ; Mon, 7 Jun 2004 11:01:58 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i57B1wMt043418 for ; Mon, 7 Jun 2004 11:01:58 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i57B1vvX043412 for freebsd-amd64@freebsd.org; Mon, 7 Jun 2004 11:01:57 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 7 Jun 2004 11:01:57 GMT Message-Id: <200406071101.i57B1vvX043412@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-amd64@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 11:01:58 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/11/26] amd64/59713 amd64 Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A01F316A4CE; Mon, 7 Jun 2004 13:25:35 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C04C43D1F; Mon, 7 Jun 2004 13:25:35 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i57DPVtD010958; Mon, 7 Jun 2004 09:25:33 -0400 (EDT) Date: Mon, 7 Jun 2004 09:25:31 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086603496.7335.29.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 13:25:35 -0000 On Mon, 7 Jun 2004, Sean McNeil wrote: > On Sun, 2004-06-06 at 22:30, Daniel Eischen wrote: > > > > It doesn't work under i386 either. Remember the nss_ldap > > problem? That was exactly the same and on i386. > > There is no nss_ldap problem. nss_ldap worked perfectly on i386. It > causes issues on amd64 because of a problem in threads. Yes, there was. See the archives (I forget if it was -current or -threads). I believe the resolver functions in libc were changed to work around it. > > > Let me make reiterate.... I am using a system that I converted from > > > i386 to amd64. Everything (all the ports) were working without any > > > problems whatsoever. These are the same exact ports that I convert over > > > to amd64. If it is not legal to do things like this then why do these > > > exact same ports work perfectly fine with freebsd/i386? > > > > > > Your analysis and assistance with this has been invaluable so far, but I > > > don't want this to just be dismissed because in principle it doesn't > > > need to be supported. IMHO, amd64 should work just like i386. Since it > > > works with i386, shouldn't we make it work for amd64? > > > > There is no difference. It isn't going to work on i386 either. > > Once you load the threads library, the libc locking functions > > will be overloaded with the locking functions in libpthread. > > When libpthread is unloaded, libc locking functions still point > > to the now non-existent library. If something tries to use > > a lock, fall down go boom. > > It worked on i386. None of the cases mentioned before unload the thread > library until an atexit. I thought they were automatically unloaded when the library was unloaded. That was the problem with nss_ldap. > > There's also the problem of overloaded functions and cancellation > > points. These won't work correctly because of ordering. It's > > like trying to use '-lc -lpthread' to link an application. > > That isn't going to work; you need '-lpthread -lc'. > > As far as I know, this works. At least for Linux and it should for > FreeBSD. The ordering doesn't matter because the overloaded routines > are actually weak references in libc and strong references in pthread. > So pthread symbols win. It doesn't work here and I don't believe ever has since libc_r was split from libc. From owner-freebsd-amd64@FreeBSD.ORG Mon Jun 7 16:21:49 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77AFE16A4CE; Mon, 7 Jun 2004 16:21:49 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B54643D5E; Mon, 7 Jun 2004 16:21:47 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id C4DFBFD03B; Mon, 7 Jun 2004 09:21:46 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09857-04; Mon, 7 Jun 2004 09:21:46 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 21E2BFD020; Mon, 7 Jun 2004 09:21:46 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1086625305.10454.33.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 07 Jun 2004 09:21:45 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 16:21:49 -0000 On Mon, 2004-06-07 at 06:25, Daniel Eischen wrote: > On Mon, 7 Jun 2004, Sean McNeil wrote: > > > On Sun, 2004-06-06 at 22:30, Daniel Eischen wrote: > > > > > > It doesn't work under i386 either. Remember the nss_ldap > > > problem? That was exactly the same and on i386. > > > > There is no nss_ldap problem. nss_ldap worked perfectly on i386. It > > causes issues on amd64 because of a problem in threads. > > Yes, there was. See the archives (I forget if it was -current > or -threads). I believe the resolver functions in libc were > changed to work around it. If you are talking about nsdispatch, then I am very intimate with the issue as I found and fixed the problem. It has to do with when an application finally shuts down. That is when it unloaded the library. > > > > Let me make reiterate.... I am using a system that I converted from > > > > i386 to amd64. Everything (all the ports) were working without any > > > > problems whatsoever. These are the same exact ports that I convert over > > > > to amd64. If it is not legal to do things like this then why do these > > > > exact same ports work perfectly fine with freebsd/i386? > > > > > > > > Your analysis and assistance with this has been invaluable so far, but I > > > > don't want this to just be dismissed because in principle it doesn't > > > > need to be supported. IMHO, amd64 should work just like i386. Since it > > > > works with i386, shouldn't we make it work for amd64? > > > > > > There is no difference. It isn't going to work on i386 either. > > > Once you load the threads library, the libc locking functions > > > will be overloaded with the locking functions in libpthread. > > > When libpthread is unloaded, libc locking functions still point > > > to the now non-existent library. If something tries to use > > > a lock, fall down go boom. > > > > It worked on i386. None of the cases mentioned before unload the thread > > library until an atexit. > > I thought they were automatically unloaded when the library > was unloaded. That was the problem with nss_ldap. During the life of any application, it usually loads extensions but doesn't unload them unless shutting down. bash was never unloading the nss_ldap, httpd was never unloading php4. This is not the issue (load/unload). > > > There's also the problem of overloaded functions and cancellation > > > points. These won't work correctly because of ordering. It's > > > like trying to use '-lc -lpthread' to link an application. > > > That isn't going to work; you need '-lpthread -lc'. > > > > As far as I know, this works. At least for Linux and it should for > > FreeBSD. The ordering doesn't matter because the overloaded routines > > are actually weak references in libc and strong references in pthread. > > So pthread symbols win. > > It doesn't work here and I don't believe ever has since libc_r > was split from libc. Many years ago, I was involved with pthreads for Linux. I helped them get things straight using the weak reference trick. I don't remember where I picked it up from, but I it was real slick how they were used to override functions in libc by having stronger references in the threading lib. libc_r and folks don't use this trick anymore? Odd. But the questions for today: Say you have an application that depends on libraries A, B, C, and libc. It then uses dlopen to load D. D depends on E, F, libpthread, and B. Is B considered to be in D's DAG? If so, then when a function within B calls a function that hasn't been bound yet in libpthread then it should bind to the threaded version. There are good arguments either way. IMHO, rtld is acting as though the answer is no and I want it to behave as yes. There is strong evidence to support this. The libreadline trace from bash and the php4 trace from httpd both only make sense if the lazy symbol resolver is not ending up with the threaded version of some call (sigaction and select respectively). Second, to save me some time can someone outline the symbol name mechanism used by libpthread? Here is what I expect: libc provides a sigaction function through a weak reference that points to some internal name (like __sigaction). libpthread provides a strong reference to sigaction thus, when loaded, overrides usage of sigaction. This should happen irregardless of whether libpthread is in the DAG for the caller (IMHO), but I'm sure there are other opinions. From owner-freebsd-amd64@FreeBSD.ORG Mon Jun 7 16:50:59 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED67D16A4CE; Mon, 7 Jun 2004 16:50:59 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A742C43D1F; Mon, 7 Jun 2004 16:50:59 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i57GoxtD000256; Mon, 7 Jun 2004 12:50:59 -0400 (EDT) Date: Mon, 7 Jun 2004 12:50:59 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086625305.10454.33.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 16:51:00 -0000 On Mon, 7 Jun 2004, Sean McNeil wrote: > On Mon, 2004-06-07 at 06:25, Daniel Eischen wrote: > > > > It doesn't work here and I don't believe ever has since libc_r > > was split from libc. > > Many years ago, I was involved with pthreads for Linux. I helped them > get things straight using the weak reference trick. I don't remember > where I picked it up from, but I it was real slick how they were used to > override functions in libc by having stronger references in the > threading lib. libc_r and folks don't use this trick anymore? Odd. > > But the questions for today: > > Say you have an application that depends on libraries A, B, C, and > libc. It then uses dlopen to load D. D depends on E, F, libpthread, > and B. Is B considered to be in D's DAG? > > If so, then when a function within B calls a function that hasn't been > bound yet in libpthread then it should bind to the threaded version. > There are good arguments either way. IMHO, rtld is acting as though the > answer is no and I want it to behave as yes. I don't know what a DAG is, but I believe I've already explained the problem. We don't litter our thread libraries with strong references for every thread interface. You must make sure references are resolved correctly by linking ordering. > There is strong evidence to support this. The libreadline trace from > bash and the php4 trace from httpd both only make sense if the lazy > symbol resolver is not ending up with the threaded version of some call > (sigaction and select respectively). > > Second, to save me some time can someone outline the symbol name > mechanism used by libpthread? Here is what I expect: > > libc provides a sigaction function through a weak reference that points > to some internal name (like __sigaction). libpthread provides a strong > reference to sigaction thus, when loaded, overrides usage of sigaction. > This should happen irregardless of whether libpthread is in the DAG for > the caller (IMHO), but I'm sure there are other opinions. There are no strong references (other than a handful that are needed by rtld). We mandate that you link things in the proper order. -- Dan Eischen From owner-freebsd-amd64@FreeBSD.ORG Mon Jun 7 17:02:59 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6554916A4CE; Mon, 7 Jun 2004 17:02:59 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2677343D58; Mon, 7 Jun 2004 17:02:59 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id CF4EAFD03B; Mon, 7 Jun 2004 10:02:58 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09857-06; Mon, 7 Jun 2004 10:02:58 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 0F114FD020; Mon, 7 Jun 2004 10:02:58 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1086627777.39706.12.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 07 Jun 2004 10:02:57 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 17:02:59 -0000 On Mon, 2004-06-07 at 09:50, Daniel Eischen wrote: > On Mon, 7 Jun 2004, Sean McNeil wrote: > > > On Mon, 2004-06-07 at 06:25, Daniel Eischen wrote: > > > > > > It doesn't work here and I don't believe ever has since libc_r > > > was split from libc. > > > > Many years ago, I was involved with pthreads for Linux. I helped them > > get things straight using the weak reference trick. I don't remember > > where I picked it up from, but I it was real slick how they were used to > > override functions in libc by having stronger references in the > > threading lib. libc_r and folks don't use this trick anymore? Odd. > > > > But the questions for today: > > > > Say you have an application that depends on libraries A, B, C, and > > libc. It then uses dlopen to load D. D depends on E, F, libpthread, > > and B. Is B considered to be in D's DAG? > > > > If so, then when a function within B calls a function that hasn't been > > bound yet in libpthread then it should bind to the threaded version. > > There are good arguments either way. IMHO, rtld is acting as though the > > answer is no and I want it to behave as yes. > > I don't know what a DAG is, but I believe I've already explained > the problem. We don't litter our thread libraries with strong > references for every thread interface. You must make sure > references are resolved correctly by linking ordering. > > > There is strong evidence to support this. The libreadline trace from > > bash and the php4 trace from httpd both only make sense if the lazy > > symbol resolver is not ending up with the threaded version of some call > > (sigaction and select respectively). > > > > Second, to save me some time can someone outline the symbol name > > mechanism used by libpthread? Here is what I expect: > > > > libc provides a sigaction function through a weak reference that points > > to some internal name (like __sigaction). libpthread provides a strong > > reference to sigaction thus, when loaded, overrides usage of sigaction. > > This should happen irregardless of whether libpthread is in the DAG for > > the caller (IMHO), but I'm sure there are other opinions. > > There are no strong references (other than a handful that are > needed by rtld). We mandate that you link things in the proper > order. Then I submit to you that signals are broken in KSE/libpthread at the very least. libpthread makes the assumption that it will take over principle control of sigaction and friends. So, if I link with "-lc -lpthread" I should use the versions in libc and it should work. If I link with "-lpthread -lc" then I should use the versions in libpthread. Yet constructors for libpthread will install hooks for signals that undermines the proper behavior of the original sigaction function. I also submit to you that FreeBSD is not behaving like any other UNIX implementation that I have worked with if this is the case. pthread functions should have precedence over their libc counterparts regardless of link order. From owner-freebsd-amd64@FreeBSD.ORG Mon Jun 7 21:49:10 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F14E16A4CE; Mon, 7 Jun 2004 21:49:10 +0000 (GMT) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8ABF243D46; Mon, 7 Jun 2004 21:49:09 +0000 (GMT) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (210.50.200.253) by smtp01.syd.iprimus.net.au (7.0.024) id 40B7A0DA002D5EE6; Tue, 8 Jun 2004 07:49:08 +1000 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id 4517241D3; Tue, 8 Jun 2004 07:50:54 +1000 (EST) Date: Tue, 8 Jun 2004 07:50:54 +1000 From: Tim Robbins To: freebsd-amd64@freebsd.org, freebsd-threads@freebsd.org Message-ID: <20040607215054.GA41798@cat.robbins.dropbear.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [tjr@FreeBSD.org: cvs commit: src/lib/libpthread/arch/amd64/amd64 context.S] X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 21:49:10 -0000 Anyone who has resorted to using libc_r instead of libpthread on amd64 should update their sources (ensuring they get context.S revision 1.6), rebuild and reinstall libpthread (or world), then give it another try. The bug I just fixed looks to have been responsible for the mysterious crashes I was seeing in Mozilla/Firefox, XMMS and GNOME. Tim ----- Forwarded message from "Tim J. Robbins" ----- From: "Tim J. Robbins" Date: Mon, 7 Jun 2004 21:25:17 +0000 (UTC) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/lib/libpthread/arch/amd64/amd64 context.S X-FreeBSD-CVS-Branch: HEAD Precedence: bulk X-Loop: FreeBSD.ORG X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=0.15.7 tjr 2004-06-07 21:25:16 UTC FreeBSD src repository Modified files: lib/libpthread/arch/amd64/amd64 context.S Log: Avoid clobbering the red zone when running on the new context's stack in _amd64_restore_context(). Revision Changes Path 1.6 +5 -0 src/lib/libpthread/arch/amd64/amd64/context.S ----- End forwarded message ----- From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 8 01:07:59 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 321B616A4E8; Tue, 8 Jun 2004 01:07:59 +0000 (GMT) Received: from exchhz01.viatech.com.cn (ip-40-162-97-218.anlai.com [218.97.162.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B63D43D49; Tue, 8 Jun 2004 01:07:55 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (DAVIDWNT [10.4.1.99]) by exchhz01.viatech.com.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id M22V47LA; Tue, 8 Jun 2004 09:07:51 +0800 Message-ID: <40C51203.8050508@freebsd.org> Date: Tue, 08 Jun 2004 09:10:27 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Robbins References: <20040607215054.GA41798@cat.robbins.dropbear.id.au> In-Reply-To: <20040607215054.GA41798@cat.robbins.dropbear.id.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: [tjr@FreeBSD.org: cvs commit:src/lib/libpthread/arch/amd64/amd64 context.S] X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 01:07:59 -0000 Is there any reason to use memory indirect jump ? did you have benchmarked context switch speed before and after this commit ? I won't use such indirect jump in speed sensitive case, it is not CPU branch trace cache friendly, it is better to use ret to match call in up level. David Xu Tim Robbins wrote: > Anyone who has resorted to using libc_r instead of libpthread on amd64 > should update their sources (ensuring they get context.S revision 1.6), > rebuild and reinstall libpthread (or world), then give it another try. > The bug I just fixed looks to have been responsible for the mysterious > crashes I was seeing in Mozilla/Firefox, XMMS and GNOME. > > > Tim > > ----- Forwarded message from "Tim J. Robbins" ----- > > From: "Tim J. Robbins" > Date: Mon, 7 Jun 2004 21:25:17 +0000 (UTC) > To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, > cvs-all@FreeBSD.org > Subject: cvs commit: src/lib/libpthread/arch/amd64/amd64 context.S > X-FreeBSD-CVS-Branch: HEAD > Precedence: bulk > X-Loop: FreeBSD.ORG > X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=0.15.7 > > tjr 2004-06-07 21:25:16 UTC > > FreeBSD src repository > > Modified files: > lib/libpthread/arch/amd64/amd64 context.S > Log: > Avoid clobbering the red zone when running on the new context's stack in > _amd64_restore_context(). > > Revision Changes Path > 1.6 +5 -0 src/lib/libpthread/arch/amd64/amd64/context.S > > ----- End forwarded message ----- > _______________________________________________ > 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" > From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 8 01:10:23 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD2EB16A4CE; Tue, 8 Jun 2004 01:10:23 +0000 (GMT) Received: from daintree.corp.yahoo.com (daintree.corp.yahoo.com [216.145.52.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81DF743D4C; Tue, 8 Jun 2004 01:10:23 +0000 (GMT) (envelope-from peter@yahoo-inc.com) Received: by daintree.corp.yahoo.com (Postfix, from userid 2154) id 7012D8826; Mon, 7 Jun 2004 18:10:23 -0700 (PDT) From: Peter Wemm To: freebsd-amd64@freebsd.org Date: Mon, 7 Jun 2004 18:10:22 -0700 User-Agent: KMail/1.6.1 References: <20040607215054.GA41798@cat.robbins.dropbear.id.au> <40C51203.8050508@freebsd.org> In-Reply-To: <40C51203.8050508@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406071810.23069.peter@wemm.org> cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: [tjr@FreeBSD.org: cvs commit:src/lib/libpthread/arch/amd64/amd64 context.S] X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 01:10:23 -0000 On Monday 07 June 2004 06:10 pm, David Xu wrote: > Is there any reason to use memory indirect jump ? did you > have benchmarked context switch speed before and after this commit ? > I won't use such indirect jump in speed sensitive case, it is > not CPU branch trace cache friendly, it is better to use > ret to match call in up level. Because the return address is already on the higher level stack frame, and copying it (read/write/ret) is more awkward than the read+indirect jump. Unfortunately, we can't indirectly access the flags register. > David Xu > > Tim Robbins wrote: > > Anyone who has resorted to using libc_r instead of libpthread on > > amd64 should update their sources (ensuring they get context.S > > revision 1.6), rebuild and reinstall libpthread (or world), then > > give it another try. The bug I just fixed looks to have been > > responsible for the mysterious crashes I was seeing in > > Mozilla/Firefox, XMMS and GNOME. > > > > > > Tim > > > > ----- Forwarded message from "Tim J. Robbins" > > ----- > > > > From: "Tim J. Robbins" > > Date: Mon, 7 Jun 2004 21:25:17 +0000 (UTC) > > To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, > > cvs-all@FreeBSD.org > > Subject: cvs commit: src/lib/libpthread/arch/amd64/amd64 context.S > > X-FreeBSD-CVS-Branch: HEAD > > Precedence: bulk > > X-Loop: FreeBSD.ORG > > X-Bogosity: No, tests=bogofilter, spamicity=0.000000, > > version=0.15.7 > > > > tjr 2004-06-07 21:25:16 UTC > > > > FreeBSD src repository > > > > Modified files: > > lib/libpthread/arch/amd64/amd64 context.S > > Log: > > Avoid clobbering the red zone when running on the new context's > > stack in _amd64_restore_context(). > > > > Revision Changes Path > > 1.6 +5 -0 > > src/lib/libpthread/arch/amd64/amd64/context.S > > > > ----- End forwarded message ----- > > _______________________________________________ > > 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" > > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to > "freebsd-amd64-unsubscribe@freebsd.org" -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 8 01:15:15 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E20A16A4CE; Tue, 8 Jun 2004 01:15:15 +0000 (GMT) Received: from exchhz01.viatech.com.cn (ip-40-162-97-218.anlai.com [218.97.162.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 164CE43D2D; Tue, 8 Jun 2004 01:15:13 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (DAVIDWNT [10.4.1.99]) by exchhz01.viatech.com.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id M22V47MS; Tue, 8 Jun 2004 09:15:05 +0800 Message-ID: <40C513B5.8070406@freebsd.org> Date: Tue, 08 Jun 2004 09:17:41 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Wemm References: <200406071810.23069.peter@wemm.org> In-Reply-To: <200406071810.23069.peter@wemm.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: [tjr@FreeBSD.org: cvscommit:src/lib/libpthread/arch/amd64/amd 64 context.S] X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 01:15:15 -0000 Peter Wemm wrote: > On Monday 07 June 2004 06:10 pm, David Xu wrote: > >>Is there any reason to use memory indirect jump ? did you >>have benchmarked context switch speed before and after this commit ? >>I won't use such indirect jump in speed sensitive case, it is >>not CPU branch trace cache friendly, it is better to use >>ret to match call in up level. > > > Because the return address is already on the higher level stack frame, > and copying it (read/write/ret) is more awkward than the read+indirect > jump. Unfortunately, we can't indirectly access the flags register. > I would like someone to test it: http://people.freebsd.org/~davidxu/kse/test/ctxswitch.c tell me the result before and after this commit. > >>David Xu >> >>Tim Robbins wrote: >> >>>Anyone who has resorted to using libc_r instead of libpthread on >>>amd64 should update their sources (ensuring they get context.S >>>revision 1.6), rebuild and reinstall libpthread (or world), then >>>give it another try. The bug I just fixed looks to have been >>>responsible for the mysterious crashes I was seeing in >>>Mozilla/Firefox, XMMS and GNOME. >>> >>> >>>Tim >>> >>>----- Forwarded message from "Tim J. Robbins" >>>----- >>> >>>From: "Tim J. Robbins" >>>Date: Mon, 7 Jun 2004 21:25:17 +0000 (UTC) >>>To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, >>> cvs-all@FreeBSD.org >>>Subject: cvs commit: src/lib/libpthread/arch/amd64/amd64 context.S >>>X-FreeBSD-CVS-Branch: HEAD >>>Precedence: bulk >>>X-Loop: FreeBSD.ORG >>>X-Bogosity: No, tests=bogofilter, spamicity=0.000000, >>>version=0.15.7 >>> >>>tjr 2004-06-07 21:25:16 UTC >>> >>> FreeBSD src repository >>> >>> Modified files: >>> lib/libpthread/arch/amd64/amd64 context.S >>> Log: >>> Avoid clobbering the red zone when running on the new context's >>>stack in _amd64_restore_context(). >>> >>> Revision Changes Path >>> 1.6 +5 -0 >>>src/lib/libpthread/arch/amd64/amd64/context.S >>> >>>----- End forwarded message ----- >>>_______________________________________________ >>>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" >> >>_______________________________________________ >>freebsd-amd64@freebsd.org mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 >>To unsubscribe, send any mail to >>"freebsd-amd64-unsubscribe@freebsd.org" > > From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 8 01:44:01 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D7E616A4CE; Tue, 8 Jun 2004 01:44:01 +0000 (GMT) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id F27ED43D1D; Tue, 8 Jun 2004 01:43:58 +0000 (GMT) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (210.50.200.253) by smtp01.syd.iprimus.net.au (7.0.024) id 40B7A0DA002E51BD; Tue, 8 Jun 2004 11:43:57 +1000 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id 8320B41D0; Tue, 8 Jun 2004 11:45:44 +1000 (EST) Date: Tue, 8 Jun 2004 11:45:44 +1000 From: Tim Robbins To: David Xu Message-ID: <20040608014544.GA43197@cat.robbins.dropbear.id.au> References: <20040607215054.GA41798@cat.robbins.dropbear.id.au> <40C51203.8050508@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40C51203.8050508@freebsd.org> User-Agent: Mutt/1.4.1i cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: [tjr@FreeBSD.org: cvs commit: src/lib/libpthread/arch/amd64/amd64 context.S] X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 01:44:01 -0000 On Tue, Jun 08, 2004 at 09:10:27AM +0800, David Xu wrote: > Is there any reason to use memory indirect jump ? did you > have benchmarked context switch speed before and after this commit ? > I won't use such indirect jump in speed sensitive case, it is > not CPU branch trace cache friendly, it is better to use > ret to match call in up level. For the reason Peter mentioned, we can't use "ret" in the general case. It may be possible to do it that way for voluntary/synchronous context switches, but it's probably not worth the effort -- even the i386 context switch functions have not been micro-optimised to this level: they save scratch registers + flags, perform redundant null pointer checks, validate mc_len, initialise and save the FPU control word for threads that don't touch the FPU, perform unaligned jumps, etc. etc. As for benchmarks: the new version runs Mozilla infinitely faster :-) Tim From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 8 02:07:55 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A85AD16A4CE; Tue, 8 Jun 2004 02:07:55 +0000 (GMT) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12D1F43D54; Tue, 8 Jun 2004 02:07:55 +0000 (GMT) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (210.50.40.174) by smtp01.syd.iprimus.net.au (7.0.024) id 40B7A0DA002E6DC6; Tue, 8 Jun 2004 12:07:53 +1000 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id CD72341D0; Tue, 8 Jun 2004 12:09:40 +1000 (EST) Date: Tue, 8 Jun 2004 12:09:40 +1000 From: Tim Robbins To: David Xu Message-ID: <20040608020940.GB43197@cat.robbins.dropbear.id.au> References: <200406071810.23069.peter@wemm.org> <40C513B5.8070406@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40C513B5.8070406@freebsd.org> User-Agent: Mutt/1.4.1i cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: [tjr@FreeBSD.org: cvscommit:src/lib/libpthread/arch/amd64/amd 64 context.S] X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 02:07:55 -0000 On Tue, Jun 08, 2004 at 09:17:41AM +0800, David Xu wrote: > Peter Wemm wrote: > > >On Monday 07 June 2004 06:10 pm, David Xu wrote: > > > >>Is there any reason to use memory indirect jump ? did you > >>have benchmarked context switch speed before and after this commit ? > >>I won't use such indirect jump in speed sensitive case, it is > >>not CPU branch trace cache friendly, it is better to use > >>ret to match call in up level. > > > > > >Because the return address is already on the higher level stack frame, > >and copying it (read/write/ret) is more awkward than the read+indirect > >jump. Unfortunately, we can't indirectly access the flags register. > > > I would like someone to test it: > http://people.freebsd.org/~davidxu/kse/test/ctxswitch.c > tell me the result before and after this commit. System: AMD Athlon 64 3000+, ASUS K8V, FreeBSD 5.2-tjr_perf with kernel config tuned for performance (no INVARIANTS, no WITNESS), multiuser mode, XFree86 + GNOME running. Test program compiled with gcc -O2 -pthread -static. ctxold = old (broken) code using ret ctxnew = new correct code using indirect jump ctxopt = same as ctxnew but does not save scratch registers or flags, redundant checks removed, jumps aligned to dword boundary $ time ./ctxold; time ./ctxnew; time ./ctxopt testing scope process context switch speed... context switches:1779631/s testing scope system context switch speed... context switches:386696/s 21.01s real 10.40s user 9.49s system testing scope process context switch speed... context switches:1823471/s testing scope system context switch speed... context switches:383949/s 21.00s real 10.34s user 9.55s system testing scope process context switch speed... context switches:1864775/s testing scope system context switch speed... context switches:386127/s 21.01s real 10.42s user 9.48s system Tim From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 8 02:57:42 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D31516A4CE; Tue, 8 Jun 2004 02:57:42 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0164A43D4C; Tue, 8 Jun 2004 02:57:39 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 401CBFD06C; Mon, 7 Jun 2004 19:57:38 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00675-03; Mon, 7 Jun 2004 19:57:36 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 0B19DFD03A; Mon, 7 Jun 2004 19:57:36 -0700 (PDT) From: Sean McNeil To: freebsd-amd64@freebsd.org, freebsd-threads@freebsd.org, freebsd-current@freebsd.org, freebsd-gnome@freebsd.org Content-Type: text/plain Message-Id: <1086663455.1258.79.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 07 Jun 2004 19:57:35 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com Subject: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 02:57:42 -0000 Up front, I'd like to make a few apologies: 1) I am sorry for the length of this email. 2) Although some very valid opinions have been expressed, I respectfully have to disagree. This email will hopefully strengthen my position. The problem: (If you just want kse threads to work for you properly, just apply the patch at the end of this email and try it out). kse threads on amd64 doesn't work with gnome. It crashes applications here and there. gnome-terminal is essentially unusable. I strongly believe this to be a binding issue. I've examined rtld and I'm satisfied that it is behaving appropriately, so I took a long hard look at how FreeBSD has implemented the pthread interface, how it is being used, and how people expect it to behave. FreeBSD pthread interface: I have no idea why, but on FreeBSD all the pthread functions are weak symbols. I have not beed given a very satisfactory answer though I have tried to understand and continue to look for enlightenment. To me, this means that there is no authorative answer to "who is the primary provider" of the weak symbols in libc. It is instead the first occurrence of the weak symbol that takes precedence. This means that if the program itself doesn't link with the pthread library yet some other library uses it then you are pretty much hosed. I've seen just this happen with plenty of gnome applications. It also means that there is an ordering dependency that I'm not sure is reasonable to enforce. Other pthread interfaces: I don't know what Linux does now, but when we first built pthreads for Linux we made the pthread library symbols definitive. They always were the overriding authority. It was modelled after what I saw in Solaris. So, taking select as an example, libc.so - internal select called something else with a weak reference to used symbol. libpthread.so - select essentially provided directly in the library or is a strong reference to an internal version. i.e. libc weak, libpthread strong. This allows for any ordering of libraries during linking. Very good (IMHO) and has other benifits as well - like security. Application issues: As mentioned above, gnome is not very usable as things stand. I had to move to libc_r to get any stability at all. Besides gnome, I have found issues with apache2/php4, wine, and bash with nss_ldap to name a few. Security: Actually, having an authorative provider of core libc functions would be very helpful to eliminating a potential security risk. An application that is linked with libpthread wouldn't be able to dlopen some other library that could potentially take over libc weak functionality. Additionally, some sort of non-threaded library could be created that blocked a program from overriding libc routines with thread versions whenever it was linked directly to the main application. Proof is in the pudding: What can I say? Some people will insist that the gnome applications are broken somehow or that what I'm saying doesn't conform to their view as how the thread libraries should work. I admit I do not fully understand the dogma behind making them all weak symbols, but so far nothing I've heard trumps the fact that doing this makes everything work. Since applying the patch below, my amd64 system has worked flawlessly with gnome and libpthread.so.1. It has not shown any of the problems that have been haunting me since I switched over from running in i386 mode. The patch: A patch to apply in /usr/src/lib/libpthread is included at the end of this email. I haven't bothered doing it for libc_r even though it should be done. Apache2/php4 would have issues, for instance, with libc_r without making the symbols strong references. Anyone else that wants to use gnome right now under amd64 might want to try out this patch. Cheers, Sean diff -c3pr thread.orig/thr_accept.c thread/thr_accept.c *** thread.orig/thr_accept.c Tue Dec 9 15:40:27 2003 --- thread/thr_accept.c Mon Jun 7 17:48:59 2004 *************** __FBSDID("$FreeBSD: src/lib/libpthread/t *** 32,39 **** #include #include "thr_private.h" - __weak_reference(__accept, accept); - int __accept(int s, struct sockaddr *addr, socklen_t *addrlen) { --- 32,37 ---- *************** __accept(int s, struct sockaddr *addr, s *** 47,49 **** --- 45,49 ---- return (ret); } + + __strong_reference(__accept, accept); diff -c3pr thread.orig/thr_aio_suspend.c thread/thr_aio_suspend.c *** thread.orig/thr_aio_suspend.c Mon Dec 8 18:20:56 2003 --- thread/thr_aio_suspend.c Mon Jun 7 17:49:10 2004 *************** *** 33,40 **** #include #include "thr_private.h" - __weak_reference(_aio_suspend, aio_suspend); - int _aio_suspend(const struct aiocb * const iocbs[], int niocb, const struct timespec *timeout) --- 33,38 ---- *************** _aio_suspend(const struct aiocb * const *** 49,51 **** --- 47,50 ---- return (ret); } + __strong_reference(_aio_suspend, aio_suspend); diff -c3pr thread.orig/thr_atfork.c thread/thr_atfork.c *** thread.orig/thr_atfork.c Tue Nov 4 19:42:10 2003 --- thread/thr_atfork.c Mon Jun 7 17:49:21 2004 *************** *** 31,38 **** #include #include "thr_private.h" - __weak_reference(_pthread_atfork, pthread_atfork); - int _pthread_atfork(void (*prepare)(void), void (*parent)(void), void (*child)(void)) --- 31,36 ---- *************** _pthread_atfork(void (*prepare)(void), v *** 54,56 **** --- 52,55 ---- return (0); } + __strong_reference(_pthread_atfork, pthread_atfork); diff -c3pr thread.orig/thr_attr_destroy.c thread/thr_attr_destroy.c *** thread.orig/thr_attr_destroy.c Mon Sep 16 01:45:33 2002 --- thread/thr_attr_destroy.c Mon Jun 7 17:49:31 2004 *************** *** 36,43 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_destroy, pthread_attr_destroy); - int _pthread_attr_destroy(pthread_attr_t *attr) { --- 36,41 ---- *************** _pthread_attr_destroy(pthread_attr_t *at *** 60,62 **** --- 58,62 ---- } return(ret); } + + __strong_reference(_pthread_attr_destroy, pthread_attr_destroy); diff -c3pr thread.orig/thr_attr_get_np.c thread/thr_attr_get_np.c *** thread.orig/thr_attr_get_np.c Sun Jul 6 21:28:23 2003 --- thread/thr_attr_get_np.c Mon Jun 7 17:49:41 2004 *************** *** 31,38 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_get_np, pthread_attr_get_np); - int _pthread_attr_get_np(pthread_t pid, pthread_attr_t *dst) { --- 31,36 ---- *************** _pthread_attr_get_np(pthread_t pid, pthr *** 52,54 **** --- 50,54 ---- return (0); } + + __strong_reference(_pthread_attr_get_np, pthread_attr_get_np); diff -c3pr thread.orig/thr_attr_getdetachstate.c thread/thr_attr_getdetachstate.c *** thread.orig/thr_attr_getdetachstate.c Mon Sep 16 01:45:33 2002 --- thread/thr_attr_getdetachstate.c Mon Jun 7 17:49:50 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_getdetachstate, pthread_attr_getdetachstate); - int _pthread_attr_getdetachstate(const pthread_attr_t *attr, int *detachstate) { --- 35,40 ---- *************** _pthread_attr_getdetachstate(const pthre *** 57,59 **** --- 55,59 ---- } return(ret); } + + __strong_reference(_pthread_attr_getdetachstate, pthread_attr_getdetachstate); diff -c3pr thread.orig/thr_attr_getguardsize.c thread/thr_attr_getguardsize.c *** thread.orig/thr_attr_getguardsize.c Mon Sep 16 01:45:33 2002 --- thread/thr_attr_getguardsize.c Mon Jun 7 17:50:04 2004 *************** *** 33,40 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_getguardsize, pthread_attr_getguardsize); - int _pthread_attr_getguardsize(const pthread_attr_t *attr, size_t *guardsize) { --- 33,38 ---- *************** _pthread_attr_getguardsize(const pthread *** 50,52 **** --- 48,52 ---- } return(ret); } + + __strong_reference(_pthread_attr_getguardsize, pthread_attr_getguardsize); diff -c3pr thread.orig/thr_attr_getinheritsched.c thread/thr_attr_getinheritsched.c *** thread.orig/thr_attr_getinheritsched.c Mon Sep 16 01:45:33 2002 --- thread/thr_attr_getinheritsched.c Mon Jun 7 17:50:13 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_getinheritsched, pthread_attr_getinheritsched); - int _pthread_attr_getinheritsched(const pthread_attr_t *attr, int *sched_inherit) { --- 35,40 ---- *************** _pthread_attr_getinheritsched(const pthr *** 49,51 **** --- 47,51 ---- return(ret); } + + __strong_reference(_pthread_attr_getinheritsched, pthread_attr_getinheritsched); diff -c3pr thread.orig/thr_attr_getschedparam.c thread/thr_attr_getschedparam.c *** thread.orig/thr_attr_getschedparam.c Mon Sep 16 01:45:33 2002 --- thread/thr_attr_getschedparam.c Mon Jun 7 17:50:21 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_getschedparam, pthread_attr_getschedparam); - int _pthread_attr_getschedparam(const pthread_attr_t *attr, struct sched_param *param) { --- 35,40 ---- *************** _pthread_attr_getschedparam(const pthrea *** 49,51 **** --- 47,51 ---- return(ret); } + + __strong_reference(_pthread_attr_getschedparam, pthread_attr_getschedparam); diff -c3pr thread.orig/thr_attr_getschedpolicy.c thread/thr_attr_getschedpolicy.c *** thread.orig/thr_attr_getschedpolicy.c Mon Sep 16 01:45:33 2002 --- thread/thr_attr_getschedpolicy.c Mon Jun 7 17:50:29 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_getschedpolicy, pthread_attr_getschedpolicy); - int _pthread_attr_getschedpolicy(const pthread_attr_t *attr, int *policy) { --- 35,40 ---- *************** _pthread_attr_getschedpolicy(const pthre *** 49,51 **** --- 47,51 ---- return(ret); } + + __strong_reference(_pthread_attr_getschedpolicy, pthread_attr_getschedpolicy); diff -c3pr thread.orig/thr_attr_getscope.c thread/thr_attr_getscope.c *** thread.orig/thr_attr_getscope.c Mon Sep 16 01:45:33 2002 --- thread/thr_attr_getscope.c Mon Jun 7 17:50:38 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_getscope, pthread_attr_getscope); - int _pthread_attr_getscope(const pthread_attr_t *attr, int *contentionscope) { --- 35,40 ---- *************** _pthread_attr_getscope(const pthread_att *** 52,54 **** --- 50,54 ---- return(ret); } + + __strong_reference(_pthread_attr_getscope, pthread_attr_getscope); diff -c3pr thread.orig/thr_attr_getstack.c thread/thr_attr_getstack.c *** thread.orig/thr_attr_getstack.c Mon Feb 10 00:48:03 2003 --- thread/thr_attr_getstack.c Mon Jun 7 17:50:46 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_getstack, pthread_attr_getstack); - int _pthread_attr_getstack(const pthread_attr_t * __restrict attr, void ** __restrict stackaddr, --- 35,40 ---- *************** _pthread_attr_getstack(const pthread_att *** 57,59 **** --- 55,58 ---- return(ret); } + __strong_reference(_pthread_attr_getstack, pthread_attr_getstack); diff -c3pr thread.orig/thr_attr_getstackaddr.c thread/thr_attr_getstackaddr.c *** thread.orig/thr_attr_getstackaddr.c Mon Sep 16 01:45:34 2002 --- thread/thr_attr_getstackaddr.c Mon Jun 7 17:50:54 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_getstackaddr, pthread_attr_getstackaddr); - int _pthread_attr_getstackaddr(const pthread_attr_t *attr, void **stackaddr) { --- 35,40 ---- *************** _pthread_attr_getstackaddr(const pthread *** 52,54 **** --- 50,54 ---- } return(ret); } + + __strong_reference(_pthread_attr_getstackaddr, pthread_attr_getstackaddr); diff -c3pr thread.orig/thr_attr_getstacksize.c thread/thr_attr_getstacksize.c *** thread.orig/thr_attr_getstacksize.c Mon Sep 16 01:45:34 2002 --- thread/thr_attr_getstacksize.c Mon Jun 7 17:51:02 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_getstacksize, pthread_attr_getstacksize); - int _pthread_attr_getstacksize(const pthread_attr_t *attr, size_t *stacksize) { --- 35,40 ---- *************** _pthread_attr_getstacksize(const pthread *** 52,54 **** --- 50,54 ---- } return(ret); } + + __strong_reference(_pthread_attr_getstacksize, pthread_attr_getstacksize); diff -c3pr thread.orig/thr_attr_init.c thread/thr_attr_init.c *** thread.orig/thr_attr_init.c Thu Jul 17 19:46:55 2003 --- thread/thr_attr_init.c Mon Jun 7 17:51:11 2004 *************** *** 37,44 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_init, pthread_attr_init); - int _pthread_attr_init(pthread_attr_t *attr) { --- 37,42 ---- *************** _pthread_attr_init(pthread_attr_t *attr) *** 61,63 **** --- 59,63 ---- } return(ret); } + + __strong_reference(_pthread_attr_init, pthread_attr_init); diff -c3pr thread.orig/thr_attr_setcreatesuspend_np.c thread/thr_attr_setcreatesuspend_np.c *** thread.orig/thr_attr_setcreatesuspend_np.c Thu Sep 25 06:53:49 2003 --- thread/thr_attr_setcreatesuspend_np.c Mon Jun 7 17:51:20 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_setcreatesuspend_np, pthread_attr_setcreatesuspend_np); - int _pthread_attr_setcreatesuspend_np(pthread_attr_t *attr) { --- 35,40 ---- *************** _pthread_attr_setcreatesuspend_np(pthrea *** 50,52 **** --- 48,52 ---- } return(ret); } + + __strong_reference(_pthread_attr_setcreatesuspend_np, pthread_attr_setcreatesuspend_np); diff -c3pr thread.orig/thr_attr_setdetachstate.c thread/thr_attr_setdetachstate.c *** thread.orig/thr_attr_setdetachstate.c Mon Sep 16 01:45:34 2002 --- thread/thr_attr_setdetachstate.c Mon Jun 7 17:51:28 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_setdetachstate, pthread_attr_setdetachstate); - int _pthread_attr_setdetachstate(pthread_attr_t *attr, int detachstate) { --- 35,40 ---- *************** _pthread_attr_setdetachstate(pthread_att *** 59,61 **** --- 57,61 ---- } return(ret); } + + __strong_reference(_pthread_attr_setdetachstate, pthread_attr_setdetachstate); diff -c3pr thread.orig/thr_attr_setguardsize.c thread/thr_attr_setguardsize.c *** thread.orig/thr_attr_setguardsize.c Sun Sep 14 15:39:44 2003 --- thread/thr_attr_setguardsize.c Mon Jun 7 17:51:39 2004 *************** *** 34,41 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_setguardsize, pthread_attr_setguardsize); - int _pthread_attr_setguardsize(pthread_attr_t *attr, size_t guardsize) { --- 34,39 ---- *************** _pthread_attr_setguardsize(pthread_attr_ *** 51,53 **** --- 49,53 ---- } return(ret); } + + __strong_reference(_pthread_attr_setguardsize, pthread_attr_setguardsize); diff -c3pr thread.orig/thr_attr_setinheritsched.c thread/thr_attr_setinheritsched.c *** thread.orig/thr_attr_setinheritsched.c Sun Sep 14 15:28:13 2003 --- thread/thr_attr_setinheritsched.c Mon Jun 7 17:51:48 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_setinheritsched, pthread_attr_setinheritsched); - int _pthread_attr_setinheritsched(pthread_attr_t *attr, int sched_inherit) { --- 35,40 ---- *************** _pthread_attr_setinheritsched(pthread_at *** 52,54 **** --- 50,54 ---- return(ret); } + + __strong_reference(_pthread_attr_setinheritsched, pthread_attr_setinheritsched); diff -c3pr thread.orig/thr_attr_setschedparam.c thread/thr_attr_setschedparam.c *** thread.orig/thr_attr_setschedparam.c Thu Apr 17 22:04:15 2003 --- thread/thr_attr_setschedparam.c Mon Jun 7 17:51:58 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_setschedparam, pthread_attr_setschedparam); - int _pthread_attr_setschedparam(pthread_attr_t *attr, const struct sched_param *param) { --- 35,40 ---- *************** _pthread_attr_setschedparam(pthread_attr *** 55,57 **** --- 53,57 ---- return(ret); } + + __strong_reference(_pthread_attr_setschedparam, pthread_attr_setschedparam); diff -c3pr thread.orig/thr_attr_setschedpolicy.c thread/thr_attr_setschedpolicy.c *** thread.orig/thr_attr_setschedpolicy.c Mon Sep 16 01:45:34 2002 --- thread/thr_attr_setschedpolicy.c Mon Jun 7 17:52:13 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_setschedpolicy, pthread_attr_setschedpolicy); - int _pthread_attr_setschedpolicy(pthread_attr_t *attr, int policy) { --- 35,40 ---- *************** _pthread_attr_setschedpolicy(pthread_att *** 51,53 **** --- 49,53 ---- return(ret); } + + __strong_reference(_pthread_attr_setschedpolicy, pthread_attr_setschedpolicy); diff -c3pr thread.orig/thr_attr_setscope.c thread/thr_attr_setscope.c *** thread.orig/thr_attr_setscope.c Sun Sep 14 15:32:28 2003 --- thread/thr_attr_setscope.c Mon Jun 7 17:52:24 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_setscope, pthread_attr_setscope); - int _pthread_attr_setscope(pthread_attr_t *attr, int contentionscope) { --- 35,40 ---- *************** _pthread_attr_setscope(pthread_attr_t *a *** 55,57 **** --- 53,57 ---- } return (ret); } + + __strong_reference(_pthread_attr_setscope, pthread_attr_setscope); diff -c3pr thread.orig/thr_attr_setstack.c thread/thr_attr_setstack.c *** thread.orig/thr_attr_setstack.c Mon Feb 10 00:48:03 2003 --- thread/thr_attr_setstack.c Mon Jun 7 17:52:33 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_setstack, pthread_attr_setstack); - int _pthread_attr_setstack(pthread_attr_t *attr, void *stackaddr, size_t stacksize) --- 35,40 ---- *************** _pthread_attr_setstack(pthread_attr_t *a *** 56,58 **** --- 54,57 ---- return(ret); } + __strong_reference(_pthread_attr_setstack, pthread_attr_setstack); diff -c3pr thread.orig/thr_attr_setstackaddr.c thread/thr_attr_setstackaddr.c *** thread.orig/thr_attr_setstackaddr.c Mon Sep 16 01:45:34 2002 --- thread/thr_attr_setstackaddr.c Mon Jun 7 17:52:47 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_setstackaddr, pthread_attr_setstackaddr); - int _pthread_attr_setstackaddr(pthread_attr_t *attr, void *stackaddr) { --- 35,40 ---- *************** _pthread_attr_setstackaddr(pthread_attr_ *** 52,54 **** --- 50,54 ---- } return(ret); } + + __strong_reference(_pthread_attr_setstackaddr, pthread_attr_setstackaddr); diff -c3pr thread.orig/thr_attr_setstacksize.c thread/thr_attr_setstacksize.c *** thread.orig/thr_attr_setstacksize.c Mon Sep 16 01:45:34 2002 --- thread/thr_attr_setstacksize.c Mon Jun 7 17:52:55 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_setstacksize, pthread_attr_setstacksize); - int _pthread_attr_setstacksize(pthread_attr_t *attr, size_t stacksize) { --- 35,40 ---- *************** _pthread_attr_setstacksize(pthread_attr_ *** 52,54 **** --- 50,54 ---- } return(ret); } + + __strong_reference(_pthread_attr_setstacksize, pthread_attr_setstacksize); diff -c3pr thread.orig/thr_barrier.c thread/thr_barrier.c *** thread.orig/thr_barrier.c Thu Sep 4 07:06:43 2003 --- thread/thr_barrier.c Mon Jun 7 18:08:22 2004 *************** *** 33,42 **** #include "un-namespace.h" #include "thr_private.h" - __weak_reference(_pthread_barrier_init, pthread_barrier_init); - __weak_reference(_pthread_barrier_wait, pthread_barrier_wait); - __weak_reference(_pthread_barrier_destroy, pthread_barrier_destroy); - int _pthread_barrier_destroy(pthread_barrier_t *barrier) { --- 33,38 ---- *************** _pthread_barrier_destroy(pthread_barrier *** 58,64 **** int _pthread_barrier_init(pthread_barrier_t *barrier, ! const pthread_barrierattr_t *attr, int count) { pthread_barrier_t bar; int ret; --- 54,60 ---- int _pthread_barrier_init(pthread_barrier_t *barrier, ! const pthread_barrierattr_t *attr, unsigned count) { pthread_barrier_t bar; int ret; *************** _pthread_barrier_wait(pthread_barrier_t *** 120,122 **** --- 116,122 ---- _pthread_mutex_unlock(&bar->b_lock); return (ret); } + + __strong_reference(_pthread_barrier_init, pthread_barrier_init); + __strong_reference(_pthread_barrier_wait, pthread_barrier_wait); + __strong_reference(_pthread_barrier_destroy, pthread_barrier_destroy); diff -c3pr thread.orig/thr_barrierattr.c thread/thr_barrierattr.c *** thread.orig/thr_barrierattr.c Thu Sep 4 07:06:43 2003 --- thread/thr_barrierattr.c Mon Jun 7 17:53:46 2004 *************** *** 33,45 **** #include #include "thr_private.h" - __weak_reference(_pthread_barrierattr_destroy, pthread_barrierattr_destroy); - __weak_reference(_pthread_barrierattr_init, pthread_barrierattr_init); - __weak_reference(_pthread_barrierattr_setpshared, - pthread_barrierattr_setpshared); - __weak_reference(_pthread_barrierattr_getpshared, - pthread_barrierattr_getpshared); - int _pthread_barrierattr_destroy(pthread_barrierattr_t *attr) { --- 33,38 ---- *************** _pthread_barrierattr_setpshared(pthread_ *** 91,93 **** --- 84,93 ---- (*attr)->pshared = pshared; return (0); } + + __strong_reference(_pthread_barrierattr_destroy, pthread_barrierattr_destroy); + __strong_reference(_pthread_barrierattr_init, pthread_barrierattr_init); + __strong_reference(_pthread_barrierattr_setpshared, + pthread_barrierattr_setpshared); + __strong_reference(_pthread_barrierattr_getpshared, + pthread_barrierattr_getpshared); diff -c3pr thread.orig/thr_cancel.c thread/thr_cancel.c *** thread.orig/thr_cancel.c Mon Dec 8 18:20:56 2003 --- thread/thr_cancel.c Mon Jun 7 17:54:07 2004 *************** *** 6,16 **** #include #include "thr_private.h" - __weak_reference(_pthread_cancel, pthread_cancel); - __weak_reference(_pthread_setcancelstate, pthread_setcancelstate); - __weak_reference(_pthread_setcanceltype, pthread_setcanceltype); - __weak_reference(_pthread_testcancel, pthread_testcancel); - static inline int checkcancel(struct pthread *curthread) { --- 6,11 ---- *************** _thr_finish_cancellation(void *arg) *** 292,294 **** --- 287,294 ---- } THR_THREAD_UNLOCK(curthread, curthread); } + + __strong_reference(_pthread_cancel, pthread_cancel); + __strong_reference(_pthread_setcancelstate, pthread_setcancelstate); + __strong_reference(_pthread_setcanceltype, pthread_setcanceltype); + __strong_reference(_pthread_testcancel, pthread_testcancel); diff -c3pr thread.orig/thr_clean.c thread/thr_clean.c *** thread.orig/thr_clean.c Thu Apr 17 22:04:15 2003 --- thread/thr_clean.c Mon Jun 7 17:54:19 2004 *************** *** 37,45 **** #include #include "thr_private.h" - __weak_reference(_pthread_cleanup_push, pthread_cleanup_push); - __weak_reference(_pthread_cleanup_pop, pthread_cleanup_pop); - void _pthread_cleanup_push(void (*routine) (void *), void *routine_arg) { --- 37,42 ---- *************** _pthread_cleanup_pop(int execute) *** 70,72 **** --- 67,72 ---- free(old); } } + + __strong_reference(_pthread_cleanup_push, pthread_cleanup_push); + __strong_reference(_pthread_cleanup_pop, pthread_cleanup_pop); diff -c3pr thread.orig/thr_close.c thread/thr_close.c *** thread.orig/thr_close.c Mon Dec 8 18:20:56 2003 --- thread/thr_close.c Mon Jun 7 17:54:27 2004 *************** *** 39,46 **** #include #include "thr_private.h" - __weak_reference(__close, close); - int __close(int fd) { --- 39,44 ---- *************** __close(int fd) *** 53,55 **** --- 51,55 ---- return (ret); } + + __strong_reference(__close, close); diff -c3pr thread.orig/thr_concurrency.c thread/thr_concurrency.c *** thread.orig/thr_concurrency.c Sat Mar 13 21:24:27 2004 --- thread/thr_concurrency.c Mon Jun 7 17:54:39 2004 *************** *** 42,50 **** static int level = 0; - __weak_reference(_pthread_getconcurrency, pthread_getconcurrency); - __weak_reference(_pthread_setconcurrency, pthread_setconcurrency); - int _pthread_getconcurrency(void) { --- 42,47 ---- *************** _thr_setmaxconcurrency(void) *** 163,165 **** --- 160,164 ---- return (ret); } + __strong_reference(_pthread_getconcurrency, pthread_getconcurrency); + __strong_reference(_pthread_setconcurrency, pthread_setconcurrency); diff -c3pr thread.orig/thr_cond.c thread/thr_cond.c *** thread.orig/thr_cond.c Mon Dec 8 18:20:56 2003 --- thread/thr_cond.c Mon Jun 7 17:55:06 2004 *************** static inline void cond_queue_enq(pthre *** 53,66 **** * versions are not and are provided for libc internal usage (which * shouldn't introduce cancellation points). */ - __weak_reference(__pthread_cond_wait, pthread_cond_wait); - __weak_reference(__pthread_cond_timedwait, pthread_cond_timedwait); - - __weak_reference(_pthread_cond_init, pthread_cond_init); - __weak_reference(_pthread_cond_destroy, pthread_cond_destroy); - __weak_reference(_pthread_cond_signal, pthread_cond_signal); - __weak_reference(_pthread_cond_broadcast, pthread_cond_broadcast); - int _pthread_cond_init(pthread_cond_t *cond, const pthread_condattr_t *cond_attr) --- 53,58 ---- *************** cond_queue_enq(pthread_cond_t cond, stru *** 814,816 **** --- 806,816 ---- THR_CONDQ_SET(pthread); pthread->data.cond = cond; } + + __strong_reference(__pthread_cond_wait, pthread_cond_wait); + __strong_reference(__pthread_cond_timedwait, pthread_cond_timedwait); + + __strong_reference(_pthread_cond_init, pthread_cond_init); + __strong_reference(_pthread_cond_destroy, pthread_cond_destroy); + __strong_reference(_pthread_cond_signal, pthread_cond_signal); + __strong_reference(_pthread_cond_broadcast, pthread_cond_broadcast); diff -c3pr thread.orig/thr_condattr_destroy.c thread/thr_condattr_destroy.c *** thread.orig/thr_condattr_destroy.c Mon Sep 16 01:45:34 2002 --- thread/thr_condattr_destroy.c Mon Jun 7 17:55:17 2004 *************** *** 36,43 **** #include #include "thr_private.h" - __weak_reference(_pthread_condattr_destroy, pthread_condattr_destroy); - int _pthread_condattr_destroy(pthread_condattr_t *attr) { --- 36,41 ---- *************** _pthread_condattr_destroy(pthread_condat *** 51,53 **** --- 49,53 ---- } return(ret); } + + __strong_reference(_pthread_condattr_destroy, pthread_condattr_destroy); diff -c3pr thread.orig/thr_condattr_init.c thread/thr_condattr_init.c *** thread.orig/thr_condattr_init.c Thu Apr 17 22:04:15 2003 --- thread/thr_condattr_init.c Mon Jun 7 17:55:25 2004 *************** *** 37,44 **** #include #include "thr_private.h" - __weak_reference(_pthread_condattr_init, pthread_condattr_init); - int _pthread_condattr_init(pthread_condattr_t *attr) { --- 37,42 ---- *************** _pthread_condattr_init(pthread_condattr_ *** 56,58 **** --- 54,58 ---- } return (ret); } + + __strong_reference(_pthread_condattr_init, pthread_condattr_init); diff -c3pr thread.orig/thr_connect.c thread/thr_connect.c *** thread.orig/thr_connect.c Tue Dec 9 15:40:27 2003 --- thread/thr_connect.c Mon Jun 7 17:55:33 2004 *************** __FBSDID("$FreeBSD: src/lib/libpthread/t *** 32,39 **** #include #include "thr_private.h" - __weak_reference(__connect, connect); - int __connect(int fd, const struct sockaddr *name, socklen_t namelen) { --- 32,37 ---- *************** __connect(int fd, const struct sockaddr *** 47,49 **** --- 45,49 ---- return (ret); } + + __strong_reference(__connect, connect); diff -c3pr thread.orig/thr_creat.c thread/thr_creat.c *** thread.orig/thr_creat.c Mon Dec 8 18:20:56 2003 --- thread/thr_creat.c Mon Jun 7 17:55:46 2004 *************** *** 35,42 **** extern int __creat(const char *, mode_t); - __weak_reference(___creat, creat); - int ___creat(const char *path, mode_t mode) { --- 35,40 ---- *************** ___creat(const char *path, mode_t mode) *** 53,55 **** --- 51,55 ---- return ret; } + + __strong_reference(___creat, creat); diff -c3pr thread.orig/thr_create.c thread/thr_create.c *** thread.orig/thr_create.c Thu Jan 8 07:37:09 2004 --- thread/thr_create.c Mon Jun 7 17:55:55 2004 *************** static void free_stack(struct pthread_at *** 64,71 **** static void thread_start(struct pthread *curthread, void *(*start_routine) (void *), void *arg); - __weak_reference(_pthread_create, pthread_create); - /* * Some notes on new thread creation and first time initializion * to enable multi-threading. --- 64,69 ---- *************** thread_start(struct pthread *curthread, *** 355,357 **** --- 353,357 ---- /* This point should never be reached. */ PANIC("Thread has resumed after exit"); } + + __strong_reference(_pthread_create, pthread_create); diff -c3pr thread.orig/thr_detach.c thread/thr_detach.c *** thread.orig/thr_detach.c Tue Jul 22 19:11:07 2003 --- thread/thr_detach.c Mon Jun 7 17:56:04 2004 *************** *** 37,44 **** #include #include "thr_private.h" - __weak_reference(_pthread_detach, pthread_detach); - int _pthread_detach(pthread_t pthread) { --- 37,42 ---- *************** _pthread_detach(pthread_t pthread) *** 115,117 **** --- 113,117 ---- /* Return the completion status: */ return (rval); } + + __strong_reference(_pthread_detach, pthread_detach); diff -c3pr thread.orig/thr_equal.c thread/thr_equal.c *** thread.orig/thr_equal.c Mon Sep 16 01:45:34 2002 --- thread/thr_equal.c Mon Jun 7 17:56:11 2004 *************** *** 34,44 **** #include #include "thr_private.h" - __weak_reference(_pthread_equal, pthread_equal); - int _pthread_equal(pthread_t t1, pthread_t t2) { /* Compare the two thread pointers: */ return (t1 == t2); } --- 34,44 ---- #include #include "thr_private.h" int _pthread_equal(pthread_t t1, pthread_t t2) { /* Compare the two thread pointers: */ return (t1 == t2); } + + __strong_reference(_pthread_equal, pthread_equal); diff -c3pr thread.orig/thr_exit.c thread/thr_exit.c *** thread.orig/thr_exit.c Sun Sep 14 15:52:16 2003 --- thread/thr_exit.c Mon Jun 7 17:56:20 2004 *************** *** 42,49 **** void _pthread_exit(void *status); - __weak_reference(_pthread_exit, pthread_exit); - void _thr_exit(char *fname, int lineno, char *msg) { --- 42,47 ---- *************** _pthread_exit(void *status) *** 147,149 **** --- 145,149 ---- /* This point should not be reached. */ PANIC("Dead thread has resumed"); } + + __strong_reference(_pthread_exit, pthread_exit); diff -c3pr thread.orig/thr_fcntl.c thread/thr_fcntl.c *** thread.orig/thr_fcntl.c Mon Dec 8 18:20:56 2003 --- thread/thr_fcntl.c Mon Jun 7 17:56:29 2004 *************** *** 38,45 **** #include #include "thr_private.h" - __weak_reference(__fcntl, fcntl); - int __fcntl(int fd, int cmd,...) { --- 38,43 ---- *************** __fcntl(int fd, int cmd,...) *** 76,78 **** --- 74,78 ---- return (ret); } + + __strong_reference(__fcntl, fcntl); diff -c3pr thread.orig/thr_fork.c thread/thr_fork.c *** thread.orig/thr_fork.c Wed Nov 5 10:18:45 2003 --- thread/thr_fork.c Mon Jun 7 17:56:39 2004 *************** *** 49,56 **** */ #pragma weak __malloc_lock - __weak_reference(_fork, fork); - pid_t _fork(void) { --- 49,54 ---- *************** _fork(void) *** 122,124 **** --- 120,124 ---- /* Return the process ID: */ return (ret); } + + __strong_reference(_fork, fork); diff -c3pr thread.orig/thr_fsync.c thread/thr_fsync.c *** thread.orig/thr_fsync.c Mon Dec 8 18:20:56 2003 --- thread/thr_fsync.c Mon Jun 7 17:56:47 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(__fsync, fsync); - int __fsync(int fd) { --- 35,40 ---- *************** __fsync(int fd) *** 49,51 **** --- 47,51 ---- return (ret); } + + __strong_reference(__fsync, fsync); diff -c3pr thread.orig/thr_getprio.c thread/thr_getprio.c *** thread.orig/thr_getprio.c Mon Sep 16 01:45:34 2002 --- thread/thr_getprio.c Mon Jun 7 17:56:56 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_getprio, pthread_getprio); - int _pthread_getprio(pthread_t pthread) { --- 35,40 ---- *************** _pthread_getprio(pthread_t pthread) *** 54,56 **** --- 52,56 ---- /* Return the thread priority or an error status: */ return (ret); } + + __strong_reference(_pthread_getprio, pthread_getprio); diff -c3pr thread.orig/thr_getschedparam.c thread/thr_getschedparam.c *** thread.orig/thr_getschedparam.c Sun Jul 6 21:28:23 2003 --- thread/thr_getschedparam.c Mon Jun 7 17:57:03 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_getschedparam, pthread_getschedparam); - int _pthread_getschedparam(pthread_t pthread, int *policy, struct sched_param *param) --- 35,40 ---- *************** _pthread_getschedparam(pthread_t pthread *** 73,75 **** --- 71,75 ---- } return (ret); } + + __strong_reference(_pthread_getschedparam, pthread_getschedparam); diff -c3pr thread.orig/thr_info.c thread/thr_info.c *** thread.orig/thr_info.c Sun Sep 21 17:40:23 2003 --- thread/thr_info.c Mon Jun 7 18:08:53 2004 *************** *** 46,53 **** static void dump_thread(int fd, pthread_t pthread, int long_version); - __weak_reference(_pthread_set_name_np, pthread_set_name_np); - struct s_thread_info { enum pthread_state state; char *name; --- 46,51 ---- *************** dump_thread(int fd, pthread_t pthread, i *** 212,218 **** /* Set the thread name for debug: */ void ! _pthread_set_name_np(pthread_t thread, char *name) { /* Check if the caller has specified a valid thread: */ if (thread != NULL && thread->magic == THR_MAGIC) { --- 210,216 ---- /* Set the thread name for debug: */ void ! _pthread_set_name_np(pthread_t thread, const char *name) { /* Check if the caller has specified a valid thread: */ if (thread != NULL && thread->magic == THR_MAGIC) { *************** _pthread_set_name_np(pthread_t thread, c *** 223,225 **** --- 221,225 ---- thread->name = strdup(name); } } + + __strong_reference(_pthread_set_name_np, pthread_set_name_np); diff -c3pr thread.orig/thr_join.c thread/thr_join.c *** thread.orig/thr_join.c Mon Dec 8 18:20:56 2003 --- thread/thr_join.c Mon Jun 7 17:57:21 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_join, pthread_join); - int _pthread_join(pthread_t pthread, void **thread_return) { --- 35,40 ---- *************** _pthread_join(pthread_t pthread, void ** *** 160,162 **** --- 158,162 ---- /* Return the completion status: */ return (ret); } + + __strong_reference(_pthread_join, pthread_join); diff -c3pr thread.orig/thr_kill.c thread/thr_kill.c *** thread.orig/thr_kill.c Sat Jun 28 02:55:02 2003 --- thread/thr_kill.c Mon Jun 7 17:57:29 2004 *************** *** 36,43 **** #include #include "thr_private.h" - __weak_reference(_pthread_kill, pthread_kill); - int _pthread_kill(pthread_t pthread, int sig) { --- 36,41 ---- *************** _pthread_kill(pthread_t pthread, int sig *** 64,66 **** --- 62,66 ---- /* Return the completion status: */ return (ret); } + + __strong_reference(_pthread_kill, pthread_kill); diff -c3pr thread.orig/thr_main_np.c thread/thr_main_np.c *** thread.orig/thr_main_np.c Thu Apr 17 22:04:16 2003 --- thread/thr_main_np.c Mon Jun 7 17:57:41 2004 *************** *** 31,38 **** #include #include "thr_private.h" - __weak_reference(_pthread_main_np, pthread_main_np); - /* * Provide the equivelant to Solaris thr_main() function */ --- 31,36 ---- *************** _pthread_main_np() *** 45,47 **** --- 43,47 ---- else return (pthread_equal(pthread_self(), _thr_initial) ? 1 : 0); } + + __strong_reference(_pthread_main_np, pthread_main_np); diff -c3pr thread.orig/thr_mattr_init.c thread/thr_mattr_init.c *** thread.orig/thr_mattr_init.c Thu Apr 17 22:04:16 2003 --- thread/thr_mattr_init.c Mon Jun 7 17:57:51 2004 *************** *** 37,44 **** #include #include "thr_private.h" - __weak_reference(_pthread_mutexattr_init, pthread_mutexattr_init); - int _pthread_mutexattr_init(pthread_mutexattr_t *attr) { --- 37,42 ---- *************** _pthread_mutexattr_init(pthread_mutexatt *** 56,58 **** --- 54,58 ---- } return (ret); } + + __strong_reference(_pthread_mutexattr_init, pthread_mutexattr_init); diff -c3pr thread.orig/thr_mattr_kind_np.c thread/thr_mattr_kind_np.c *** thread.orig/thr_mattr_kind_np.c Mon Sep 16 01:45:35 2002 --- thread/thr_mattr_kind_np.c Mon Jun 7 17:58:11 2004 *************** *** 35,45 **** #include #include "thr_private.h" - __weak_reference(_pthread_mutexattr_setkind_np, pthread_mutexattr_setkind_np); - __weak_reference(_pthread_mutexattr_getkind_np, pthread_mutexattr_getkind_np); - __weak_reference(_pthread_mutexattr_gettype, pthread_mutexattr_gettype); - __weak_reference(_pthread_mutexattr_settype, pthread_mutexattr_settype); - int _pthread_mutexattr_setkind_np(pthread_mutexattr_t *attr, int kind) { --- 35,40 ---- *************** _pthread_mutexattr_gettype(pthread_mutex *** 95,97 **** --- 90,97 ---- } return ret; } + + __strong_reference(_pthread_mutexattr_setkind_np, pthread_mutexattr_setkind_np); + __strong_reference(_pthread_mutexattr_getkind_np, pthread_mutexattr_getkind_np); + __strong_reference(_pthread_mutexattr_gettype, pthread_mutexattr_gettype); + __strong_reference(_pthread_mutexattr_settype, pthread_mutexattr_settype); diff -c3pr thread.orig/thr_msync.c thread/thr_msync.c *** thread.orig/thr_msync.c Mon Dec 8 18:20:56 2003 --- thread/thr_msync.c Mon Jun 7 17:58:24 2004 *************** *** 11,18 **** #include #include "thr_private.h" - __weak_reference(__msync, msync); - int __msync(void *addr, size_t len, int flags) { --- 11,16 ---- *************** __msync(void *addr, size_t len, int flag *** 31,33 **** --- 29,33 ---- return ret; } + + __strong_reference(__msync, msync); diff -c3pr thread.orig/thr_multi_np.c thread/thr_multi_np.c *** thread.orig/thr_multi_np.c Thu May 23 21:32:28 2002 --- thread/thr_multi_np.c Mon Jun 7 17:58:35 2004 *************** *** 34,41 **** #include #include - __weak_reference(_pthread_multi_np, pthread_multi_np); - int _pthread_multi_np() { --- 34,39 ---- *************** _pthread_multi_np() *** 48,50 **** --- 46,50 ---- pthread_resume_all_np(); return (0); } + + __strong_reference(_pthread_multi_np, pthread_multi_np); diff -c3pr thread.orig/thr_mutex.c thread/thr_mutex.c *** thread.orig/thr_mutex.c Fri Jan 16 19:09:57 2004 --- thread/thr_mutex.c Mon Jun 7 17:59:07 2004 *************** static struct pthread_mutex_attr static_ *** 91,108 **** PTHREAD_MUTEXATTR_STATIC_INITIALIZER; static pthread_mutexattr_t static_mattr = &static_mutex_attr; - /* Single underscore versions provided for libc internal usage: */ - __weak_reference(__pthread_mutex_lock, pthread_mutex_lock); - __weak_reference(__pthread_mutex_timedlock, pthread_mutex_timedlock); - __weak_reference(__pthread_mutex_trylock, pthread_mutex_trylock); - - /* No difference between libc and application usage of these: */ - __weak_reference(_pthread_mutex_init, pthread_mutex_init); - __weak_reference(_pthread_mutex_destroy, pthread_mutex_destroy); - __weak_reference(_pthread_mutex_unlock, pthread_mutex_unlock); - - - int _pthread_mutex_init(pthread_mutex_t *mutex, const pthread_mutexattr_t *mutex_attr) --- 91,96 ---- *************** mutex_queue_enq(pthread_mutex_t mutex, p *** 1756,1758 **** --- 1744,1756 ---- } pthread->sflags |= THR_FLAGS_IN_SYNCQ; } + + /* Single underscore versions provided for libc internal usage: */ + __strong_reference(__pthread_mutex_lock, pthread_mutex_lock); + __strong_reference(__pthread_mutex_timedlock, pthread_mutex_timedlock); + __strong_reference(__pthread_mutex_trylock, pthread_mutex_trylock); + + /* No difference between libc and application usage of these: */ + __strong_reference(_pthread_mutex_init, pthread_mutex_init); + __strong_reference(_pthread_mutex_destroy, pthread_mutex_destroy); + __strong_reference(_pthread_mutex_unlock, pthread_mutex_unlock); diff -c3pr thread.orig/thr_mutex_prioceiling.c thread/thr_mutex_prioceiling.c *** thread.orig/thr_mutex_prioceiling.c Sun Jul 6 21:28:23 2003 --- thread/thr_mutex_prioceiling.c Mon Jun 7 17:59:30 2004 *************** *** 37,47 **** #include #include "thr_private.h" - __weak_reference(_pthread_mutexattr_getprioceiling, pthread_mutexattr_getprioceiling); - __weak_reference(_pthread_mutexattr_setprioceiling, pthread_mutexattr_setprioceiling); - __weak_reference(_pthread_mutex_getprioceiling, pthread_mutex_getprioceiling); - __weak_reference(_pthread_mutex_setprioceiling, pthread_mutex_setprioceiling); - int _pthread_mutexattr_getprioceiling(pthread_mutexattr_t *mattr, int *prioceiling) { --- 37,42 ---- *************** _pthread_mutex_setprioceiling(pthread_mu *** 113,115 **** --- 108,115 ---- } return(ret); } + + __strong_reference(_pthread_mutexattr_getprioceiling, pthread_mutexattr_getprioceiling); + __strong_reference(_pthread_mutexattr_setprioceiling, pthread_mutexattr_setprioceiling); + __strong_reference(_pthread_mutex_getprioceiling, pthread_mutex_getprioceiling); + __strong_reference(_pthread_mutex_setprioceiling, pthread_mutex_setprioceiling); diff -c3pr thread.orig/thr_mutex_protocol.c thread/thr_mutex_protocol.c *** thread.orig/thr_mutex_protocol.c Thu Apr 17 22:04:16 2003 --- thread/thr_mutex_protocol.c Mon Jun 7 17:59:53 2004 *************** *** 37,45 **** #include #include "thr_private.h" - __weak_reference(_pthread_mutexattr_getprotocol, pthread_mutexattr_getprotocol); - __weak_reference(_pthread_mutexattr_setprotocol, pthread_mutexattr_setprotocol); - int _pthread_mutexattr_getprotocol(pthread_mutexattr_t *mattr, int *protocol) { --- 37,42 ---- *************** _pthread_mutexattr_setprotocol(pthread_m *** 68,70 **** --- 65,69 ---- return(ret); } + __strong_reference(_pthread_mutexattr_getprotocol, pthread_mutexattr_getprotocol); + __strong_reference(_pthread_mutexattr_setprotocol, pthread_mutexattr_setprotocol); diff -c3pr thread.orig/thr_mutexattr_destroy.c thread/thr_mutexattr_destroy.c *** thread.orig/thr_mutexattr_destroy.c Mon Sep 16 01:45:35 2002 --- thread/thr_mutexattr_destroy.c Mon Jun 7 18:00:04 2004 *************** *** 36,43 **** #include #include "thr_private.h" - __weak_reference(_pthread_mutexattr_destroy, pthread_mutexattr_destroy); - int _pthread_mutexattr_destroy(pthread_mutexattr_t *attr) { --- 36,41 ---- *************** _pthread_mutexattr_destroy(pthread_mutex *** 51,53 **** --- 49,53 ---- } return(ret); } + + __strong_reference(_pthread_mutexattr_destroy, pthread_mutexattr_destroy); diff -c3pr thread.orig/thr_nanosleep.c thread/thr_nanosleep.c *** thread.orig/thr_nanosleep.c Mon Dec 8 18:20:56 2003 --- thread/thr_nanosleep.c Mon Jun 7 18:00:12 2004 *************** *** 36,43 **** #include #include "thr_private.h" - __weak_reference(__nanosleep, nanosleep); - int _nanosleep(const struct timespec *time_to_sleep, struct timespec *time_remaining) --- 36,41 ---- *************** __nanosleep(const struct timespec *time_ *** 127,129 **** --- 125,129 ---- return (ret); } + + __strong_reference(__nanosleep, nanosleep); diff -c3pr thread.orig/thr_once.c thread/thr_once.c *** thread.orig/thr_once.c Tue Sep 9 15:38:12 2003 --- thread/thr_once.c Mon Jun 7 18:00:24 2004 *************** *** 36,43 **** #include "un-namespace.h" #include "thr_private.h" - __weak_reference(_pthread_once, pthread_once); - #define ONCE_NEVER_DONE PTHREAD_NEEDS_INIT #define ONCE_DONE PTHREAD_DONE_INIT #define ONCE_IN_PROGRESS 0x02 --- 36,41 ---- *************** _pthread_once(pthread_once_t *once_contr *** 94,96 **** --- 92,95 ---- return (0); } + __strong_reference(_pthread_once, pthread_once); diff -c3pr thread.orig/thr_open.c thread/thr_open.c *** thread.orig/thr_open.c Mon Dec 8 18:20:56 2003 --- thread/thr_open.c Mon Jun 7 18:00:32 2004 *************** *** 40,47 **** #include #include "thr_private.h" - __weak_reference(__open, open); - int __open(const char *path, int flags,...) { --- 40,45 ---- *************** __open(const char *path, int flags,...) *** 69,71 **** --- 67,71 ---- return ret; } + + __strong_reference(__open, open); diff -c3pr thread.orig/thr_pause.c thread/thr_pause.c *** thread.orig/thr_pause.c Mon Dec 8 18:20:56 2003 --- thread/thr_pause.c Mon Jun 7 18:00:43 2004 *************** *** 35,42 **** extern int __pause(void); - __weak_reference(_pause, pause); - int _pause(void) { --- 35,40 ---- *************** _pause(void) *** 49,51 **** --- 47,51 ---- return ret; } + + __strong_reference(_pause, pause); diff -c3pr thread.orig/thr_poll.c thread/thr_poll.c *** thread.orig/thr_poll.c Mon Dec 8 18:20:56 2003 --- thread/thr_poll.c Mon Jun 7 18:00:57 2004 *************** *** 41,47 **** #include #include "thr_private.h" - __weak_reference(__poll, poll); int __poll(struct pollfd *fds, unsigned int nfds, int timeout) --- 41,46 ---- *************** __poll(struct pollfd *fds, unsigned int *** 55,57 **** --- 54,58 ---- return ret; } + + __strong_reference(__poll, poll); diff -c3pr thread.orig/thr_pselect.c thread/thr_pselect.c *** thread.orig/thr_pselect.c Mon Dec 8 18:20:56 2003 --- thread/thr_pselect.c Mon Jun 7 18:01:06 2004 *************** __FBSDID("$FreeBSD: src/lib/libpthread/t *** 40,47 **** extern int __pselect(int count, fd_set *rfds, fd_set *wfds, fd_set *efds, const struct timespec *timo, const sigset_t *mask); - __weak_reference(_pselect, pselect); - int _pselect(int count, fd_set *rfds, fd_set *wfds, fd_set *efds, const struct timespec *timo, const sigset_t *mask) --- 40,45 ---- *************** _pselect(int count, fd_set *rfds, fd_set *** 55,57 **** --- 53,57 ---- return (ret); } + + __strong_reference(_pselect, pselect); diff -c3pr thread.orig/thr_pspinlock.c thread/thr_pspinlock.c *** thread.orig/thr_pspinlock.c Tue Nov 4 11:56:12 2003 --- thread/thr_pspinlock.c Mon Jun 7 18:01:16 2004 *************** *** 34,45 **** #define SPIN_COUNT 10000 - __weak_reference(_pthread_spin_init, pthread_spin_init); - __weak_reference(_pthread_spin_destroy, pthread_spin_destroy); - __weak_reference(_pthread_spin_trylock, pthread_spin_trylock); - __weak_reference(_pthread_spin_lock, pthread_spin_lock); - __weak_reference(_pthread_spin_unlock, pthread_spin_unlock); - int _pthread_spin_init(pthread_spinlock_t *lock, int pshared) { --- 34,39 ---- *************** _pthread_spin_unlock(pthread_spinlock_t *** 158,160 **** --- 152,159 ---- return (ret); } + __strong_reference(_pthread_spin_init, pthread_spin_init); + __strong_reference(_pthread_spin_destroy, pthread_spin_destroy); + __strong_reference(_pthread_spin_trylock, pthread_spin_trylock); + __strong_reference(_pthread_spin_lock, pthread_spin_lock); + __strong_reference(_pthread_spin_unlock, pthread_spin_unlock); diff -c3pr thread.orig/thr_raise.c thread/thr_raise.c *** thread.orig/thr_raise.c Fri Jul 18 22:25:49 2003 --- thread/thr_raise.c Mon Jun 7 18:01:27 2004 *************** *** 33,40 **** #include #include "thr_private.h" - __weak_reference(_raise, raise); - int _raise(int sig) { --- 33,38 ---- *************** _raise(int sig) *** 51,53 **** --- 49,53 ---- } return (ret); } + + __strong_reference(_raise, raise); diff -c3pr thread.orig/thr_read.c thread/thr_read.c *** thread.orig/thr_read.c Mon Dec 8 18:20:56 2003 --- thread/thr_read.c Mon Jun 7 18:01:40 2004 *************** *** 40,47 **** #include #include "thr_private.h" - __weak_reference(__read, read); - ssize_t __read(int fd, void *buf, size_t nbytes) { --- 40,45 ---- *************** __read(int fd, void *buf, size_t nbytes) *** 54,56 **** --- 52,56 ---- return ret; } + + __strong_reference(__read, read); diff -c3pr thread.orig/thr_readv.c thread/thr_readv.c *** thread.orig/thr_readv.c Mon Dec 8 18:20:56 2003 --- thread/thr_readv.c Mon Jun 7 18:01:57 2004 *************** *** 40,47 **** #include #include "thr_private.h" - __weak_reference(__readv, readv); - ssize_t __readv(int fd, const struct iovec *iov, int iovcnt) { --- 40,45 ---- *************** __readv(int fd, const struct iovec *iov, *** 54,56 **** --- 52,56 ---- return ret; } + + __strong_reference(__readv, readv); diff -c3pr thread.orig/thr_resume_np.c thread/thr_resume_np.c *** thread.orig/thr_resume_np.c Tue Jul 22 19:11:07 2003 --- thread/thr_resume_np.c Mon Jun 7 18:02:16 2004 *************** *** 37,46 **** static struct kse_mailbox *resume_common(struct pthread *); - __weak_reference(_pthread_resume_np, pthread_resume_np); - __weak_reference(_pthread_resume_all_np, pthread_resume_all_np); - - /* Resume a thread: */ int _pthread_resume_np(pthread_t thread) --- 37,42 ---- *************** resume_common(struct pthread *thread) *** 105,107 **** --- 101,106 ---- else return (NULL); } + + __strong_reference(_pthread_resume_np, pthread_resume_np); + __strong_reference(_pthread_resume_all_np, pthread_resume_all_np); diff -c3pr thread.orig/thr_rwlock.c thread/thr_rwlock.c *** thread.orig/thr_rwlock.c Thu Jan 8 07:37:09 2004 --- thread/thr_rwlock.c Mon Jun 7 18:02:29 2004 *************** *** 38,53 **** /* maximum number of times a read lock may be obtained */ #define MAX_READ_LOCKS (INT_MAX - 1) - __weak_reference(_pthread_rwlock_destroy, pthread_rwlock_destroy); - __weak_reference(_pthread_rwlock_init, pthread_rwlock_init); - __weak_reference(_pthread_rwlock_rdlock, pthread_rwlock_rdlock); - __weak_reference(_pthread_rwlock_timedrdlock, pthread_rwlock_timedrdlock); - __weak_reference(_pthread_rwlock_tryrdlock, pthread_rwlock_tryrdlock); - __weak_reference(_pthread_rwlock_trywrlock, pthread_rwlock_trywrlock); - __weak_reference(_pthread_rwlock_unlock, pthread_rwlock_unlock); - __weak_reference(_pthread_rwlock_wrlock, pthread_rwlock_wrlock); - __weak_reference(_pthread_rwlock_timedwrlock, pthread_rwlock_timedwrlock); - /* * Prototypes */ --- 38,43 ---- *************** _pthread_rwlock_timedwrlock (pthread_rwl *** 417,419 **** --- 407,419 ---- { return (rwlock_wrlock_common (rwlock, abstime)); } + + __strong_reference(_pthread_rwlock_destroy, pthread_rwlock_destroy); + __strong_reference(_pthread_rwlock_init, pthread_rwlock_init); + __strong_reference(_pthread_rwlock_rdlock, pthread_rwlock_rdlock); + __strong_reference(_pthread_rwlock_timedrdlock, pthread_rwlock_timedrdlock); + __strong_reference(_pthread_rwlock_tryrdlock, pthread_rwlock_tryrdlock); + __strong_reference(_pthread_rwlock_trywrlock, pthread_rwlock_trywrlock); + __strong_reference(_pthread_rwlock_unlock, pthread_rwlock_unlock); + __strong_reference(_pthread_rwlock_wrlock, pthread_rwlock_wrlock); + __strong_reference(_pthread_rwlock_timedwrlock, pthread_rwlock_timedwrlock); diff -c3pr thread.orig/thr_rwlockattr.c thread/thr_rwlockattr.c *** thread.orig/thr_rwlockattr.c Mon Sep 16 01:45:35 2002 --- thread/thr_rwlockattr.c Mon Jun 7 18:02:44 2004 *************** *** 32,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_rwlockattr_destroy, pthread_rwlockattr_destroy); - __weak_reference(_pthread_rwlockattr_getpshared, pthread_rwlockattr_getpshared); - __weak_reference(_pthread_rwlockattr_init, pthread_rwlockattr_init); - __weak_reference(_pthread_rwlockattr_setpshared, pthread_rwlockattr_setpshared); - int _pthread_rwlockattr_destroy(pthread_rwlockattr_t *rwlockattr) { --- 32,37 ---- *************** _pthread_rwlockattr_setpshared(pthread_r *** 96,98 **** --- 91,97 ---- return(0); } + __strong_reference(_pthread_rwlockattr_destroy, pthread_rwlockattr_destroy); + __strong_reference(_pthread_rwlockattr_getpshared, pthread_rwlockattr_getpshared); + __strong_reference(_pthread_rwlockattr_init, pthread_rwlockattr_init); + __strong_reference(_pthread_rwlockattr_setpshared, pthread_rwlockattr_setpshared); diff -c3pr thread.orig/thr_select.c thread/thr_select.c *** thread.orig/thr_select.c Mon Dec 8 18:20:56 2003 --- thread/thr_select.c Mon Jun 7 18:02:56 2004 *************** *** 43,50 **** #include #include "thr_private.h" - __weak_reference(__select, select); - int __select(int numfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout) --- 43,48 ---- *************** __select(int numfds, fd_set *readfds, fd *** 63,65 **** --- 61,65 ---- } return ret; } + + __strong_reference(__select, select); diff -c3pr thread.orig/thr_self.c thread/thr_self.c *** thread.orig/thr_self.c Thu Apr 17 22:04:16 2003 --- thread/thr_self.c Mon Jun 7 18:03:06 2004 *************** *** 34,41 **** #include #include "thr_private.h" - __weak_reference(_pthread_self, pthread_self); - pthread_t _pthread_self(void) { --- 34,39 ---- *************** _pthread_self(void) *** 45,47 **** --- 43,47 ---- /* Return the running thread pointer: */ return (_get_curthread()); } + + __strong_reference(_pthread_self, pthread_self); diff -c3pr thread.orig/thr_sem.c thread/thr_sem.c *** thread.orig/thr_sem.c Fri Feb 6 07:20:56 2004 --- thread/thr_sem.c Mon Jun 7 18:09:50 2004 *************** extern int pthread_cond_wait(pthread_con *** 47,58 **** extern int pthread_cond_timedwait(pthread_cond_t *, pthread_mutex_t *, struct timespec *); - __weak_reference(_sem_init, sem_init); - __weak_reference(_sem_wait, sem_wait); - __weak_reference(_sem_timedwait, sem_timedwait); - __weak_reference(_sem_post, sem_post); - - static inline int sem_check_validity(sem_t *sem) { --- 47,52 ---- *************** _sem_wait(sem_t *sem) *** 173,179 **** int _sem_timedwait(sem_t * __restrict sem, ! struct timespec * __restrict abs_timeout) { struct pthread *curthread; int retval; --- 167,173 ---- int _sem_timedwait(sem_t * __restrict sem, ! const struct timespec * __restrict abs_timeout) { struct pthread *curthread; int retval; *************** _sem_post(sem_t *sem) *** 260,262 **** --- 254,261 ---- return (retval); } + + __strong_reference(_sem_init, sem_init); + __strong_reference(_sem_wait, sem_wait); + __strong_reference(_sem_timedwait, sem_timedwait); + __strong_reference(_sem_post, sem_post); diff -c3pr thread.orig/thr_setprio.c thread/thr_setprio.c *** thread.orig/thr_setprio.c Mon Sep 16 01:45:36 2002 --- thread/thr_setprio.c Mon Jun 7 18:03:28 2004 *************** *** 34,41 **** #include #include "thr_private.h" - __weak_reference(_pthread_setprio, pthread_setprio); - int _pthread_setprio(pthread_t pthread, int prio) { --- 34,39 ---- *************** _pthread_setprio(pthread_t pthread, int *** 50,52 **** --- 48,52 ---- /* Return the error status: */ return (ret); } + + __strong_reference(_pthread_setprio, pthread_setprio); diff -c3pr thread.orig/thr_setschedparam.c thread/thr_setschedparam.c *** thread.orig/thr_setschedparam.c Sun Apr 20 21:02:56 2003 --- thread/thr_setschedparam.c Mon Jun 7 18:03:37 2004 *************** *** 36,43 **** #include #include "thr_private.h" - __weak_reference(_pthread_setschedparam, pthread_setschedparam); - int _pthread_setschedparam(pthread_t pthread, int policy, const struct sched_param *param) --- 36,41 ---- *************** _pthread_setschedparam(pthread_t pthread *** 134,136 **** --- 132,136 ---- } return (ret); } + + __strong_reference(_pthread_setschedparam, pthread_setschedparam); diff -c3pr thread.orig/thr_sigaction.c thread/thr_sigaction.c *** thread.orig/thr_sigaction.c Wed Sep 24 23:23:40 2003 --- thread/thr_sigaction.c Mon Jun 7 18:03:50 2004 *************** *** 36,43 **** #include #include "thr_private.h" - __weak_reference(_sigaction, sigaction); - int _sigaction(int sig, const struct sigaction * act, struct sigaction * oact) { --- 36,41 ---- *************** _sigaction(int sig, const struct sigacti *** 115,117 **** --- 113,117 ---- /* Return the completion status: */ return (ret); } + + __strong_reference(_sigaction, sigaction); diff -c3pr thread.orig/thr_sigaltstack.c thread/thr_sigaltstack.c *** thread.orig/thr_sigaltstack.c Thu Jan 1 16:38:42 2004 --- thread/thr_sigaltstack.c Mon Jun 7 18:10:59 2004 *************** __FBSDID("$FreeBSD: src/lib/libpthread/t *** 31,40 **** #include #include "thr_private.h" - __weak_reference(_sigaltstack, sigaltstack); - int ! _sigaltstack(stack_t *_ss, stack_t *_oss) { struct pthread *curthread = _get_curthread(); stack_t ss, oss; --- 31,38 ---- #include #include "thr_private.h" int ! _sigaltstack(const stack_t *_ss, stack_t *_oss) { struct pthread *curthread = _get_curthread(); stack_t ss, oss; *************** _thr_sigonstack(void *sp) *** 105,107 **** --- 103,106 ---- : 0); } + __strong_reference(_sigaltstack, sigaltstack); diff -c3pr thread.orig/thr_sigmask.c thread/thr_sigmask.c *** thread.orig/thr_sigmask.c Thu Sep 18 05:19:28 2003 --- thread/thr_sigmask.c Mon Jun 7 18:04:07 2004 *************** *** 40,47 **** #include #include "thr_private.h" - __weak_reference(_pthread_sigmask, pthread_sigmask); - int _pthread_sigmask(int how, const sigset_t *set, sigset_t *oset) { --- 40,45 ---- *************** _pthread_sigmask(int how, const sigset_t *** 111,113 **** --- 109,113 ---- *oset = oldset; return (ret); } + + __strong_reference(_pthread_sigmask, pthread_sigmask); diff -c3pr thread.orig/thr_sigpending.c thread/thr_sigpending.c *** thread.orig/thr_sigpending.c Sun Aug 17 20:58:29 2003 --- thread/thr_sigpending.c Mon Jun 7 18:04:15 2004 *************** *** 39,46 **** #include #include "thr_private.h" - __weak_reference(_sigpending, sigpending); - int _sigpending(sigset_t *set) { --- 39,44 ---- *************** _sigpending(sigset_t *set) *** 71,73 **** --- 69,73 ---- /* Return the completion status: */ return (ret); } + + __strong_reference(_sigpending, sigpending); diff -c3pr thread.orig/thr_sigprocmask.c thread/thr_sigprocmask.c *** thread.orig/thr_sigprocmask.c Sun Aug 17 20:58:29 2003 --- thread/thr_sigprocmask.c Mon Jun 7 18:04:24 2004 *************** *** 39,46 **** #include #include "thr_private.h" - __weak_reference(_sigprocmask, sigprocmask); - int _sigprocmask(int how, const sigset_t *set, sigset_t *oset) { --- 39,44 ---- *************** _sigprocmask(int how, const sigset_t *se *** 53,55 **** --- 51,55 ---- } return (ret); } + + __strong_reference(_sigprocmask, sigprocmask); diff -c3pr thread.orig/thr_sigsuspend.c thread/thr_sigsuspend.c *** thread.orig/thr_sigsuspend.c Mon Dec 8 18:20:56 2003 --- thread/thr_sigsuspend.c Mon Jun 7 18:04:32 2004 *************** *** 38,45 **** #include #include "thr_private.h" - __weak_reference(__sigsuspend, sigsuspend); - int _sigsuspend(const sigset_t *set) { --- 38,43 ---- *************** __sigsuspend(const sigset_t * set) *** 101,103 **** --- 99,103 ---- return (ret); } + + __strong_reference(__sigsuspend, sigsuspend); diff -c3pr thread.orig/thr_sigwait.c thread/thr_sigwait.c *** thread.orig/thr_sigwait.c Tue Mar 16 18:12:19 2004 --- thread/thr_sigwait.c Mon Jun 7 18:04:44 2004 *************** *** 39,48 **** #include #include "thr_private.h" - __weak_reference(__sigwait, sigwait); - __weak_reference(__sigtimedwait, sigtimedwait); - __weak_reference(__sigwaitinfo, sigwaitinfo); - static int lib_sigtimedwait(const sigset_t *set, siginfo_t *info, const struct timespec * timeout) --- 39,44 ---- *************** _sigwait(const sigset_t *set, int *sig) *** 200,202 **** --- 196,201 ---- return (ret); } + __strong_reference(__sigwait, sigwait); + __strong_reference(__sigtimedwait, sigtimedwait); + __strong_reference(__sigwaitinfo, sigwaitinfo); diff -c3pr thread.orig/thr_single_np.c thread/thr_single_np.c *** thread.orig/thr_single_np.c Thu May 23 21:32:28 2002 --- thread/thr_single_np.c Mon Jun 7 18:04:56 2004 *************** *** 34,41 **** #include #include - __weak_reference(_pthread_single_np, pthread_single_np); - int _pthread_single_np() { --- 34,39 ---- *************** int _pthread_single_np() *** 47,49 **** --- 45,49 ---- */ return (0); } + + __strong_reference(_pthread_single_np, pthread_single_np); diff -c3pr thread.orig/thr_sleep.c thread/thr_sleep.c *** thread.orig/thr_sleep.c Mon Dec 8 18:20:56 2003 --- thread/thr_sleep.c Mon Jun 7 18:05:04 2004 *************** *** 35,42 **** extern unsigned int __sleep(unsigned int); - __weak_reference(_sleep, sleep); - unsigned int _sleep(unsigned int seconds) { --- 35,40 ---- *************** _sleep(unsigned int seconds) *** 49,51 **** --- 47,51 ---- return (ret); } + + __strong_reference(_sleep, sleep); diff -c3pr thread.orig/thr_spec.c thread/thr_spec.c *** thread.orig/thr_spec.c Tue Aug 19 19:34:14 2003 --- thread/thr_spec.c Mon Jun 7 18:05:14 2004 *************** struct pthread_key { *** 48,59 **** /* Static variables: */ static struct pthread_key key_table[PTHREAD_KEYS_MAX]; - __weak_reference(_pthread_key_create, pthread_key_create); - __weak_reference(_pthread_key_delete, pthread_key_delete); - __weak_reference(_pthread_getspecific, pthread_getspecific); - __weak_reference(_pthread_setspecific, pthread_setspecific); - - int _pthread_key_create(pthread_key_t *key, void (*destructor) (void *)) { --- 48,53 ---- *************** _pthread_getspecific(pthread_key_t key) *** 232,234 **** --- 226,233 ---- data = NULL; return (data); } + + __strong_reference(_pthread_key_create, pthread_key_create); + __strong_reference(_pthread_key_delete, pthread_key_delete); + __strong_reference(_pthread_getspecific, pthread_getspecific); + __strong_reference(_pthread_setspecific, pthread_setspecific); diff -c3pr thread.orig/thr_suspend_np.c thread/thr_suspend_np.c *** thread.orig/thr_suspend_np.c Sun May 4 09:17:01 2003 --- thread/thr_suspend_np.c Mon Jun 7 18:05:26 2004 *************** *** 37,45 **** static void suspend_common(struct pthread *thread); - __weak_reference(_pthread_suspend_np, pthread_suspend_np); - __weak_reference(_pthread_suspend_all_np, pthread_suspend_all_np); - /* Suspend a thread: */ int _pthread_suspend_np(pthread_t thread) --- 37,42 ---- *************** suspend_common(struct pthread *thread) *** 107,109 **** --- 104,109 ---- #endif } } + + __strong_reference(_pthread_suspend_np, pthread_suspend_np); + __strong_reference(_pthread_suspend_all_np, pthread_suspend_all_np); diff -c3pr thread.orig/thr_switch_np.c thread/thr_switch_np.c *** thread.orig/thr_switch_np.c Thu Apr 17 22:04:16 2003 --- thread/thr_switch_np.c Mon Jun 7 18:05:36 2004 *************** *** 36,45 **** #include #include "thr_private.h" - - __weak_reference(_pthread_switch_add_np, pthread_switch_add_np); - __weak_reference(_pthread_switch_delete_np, pthread_switch_delete_np); - int _pthread_switch_add_np(pthread_switch_routine_t routine) { --- 36,41 ---- *************** _pthread_switch_delete_np(pthread_switch *** 51,53 **** --- 47,52 ---- { return (ENOTSUP); } + + __strong_reference(_pthread_switch_add_np, pthread_switch_add_np); + __strong_reference(_pthread_switch_delete_np, pthread_switch_delete_np); diff -c3pr thread.orig/thr_system.c thread/thr_system.c *** thread.orig/thr_system.c Mon Dec 8 18:20:56 2003 --- thread/thr_system.c Mon Jun 7 18:05:44 2004 *************** *** 35,42 **** extern int __system(const char *); - __weak_reference(_system, system); - int _system(const char *string) { --- 35,40 ---- *************** _system(const char *string) *** 49,51 **** --- 47,51 ---- return ret; } + + __strong_reference(_system, system); diff -c3pr thread.orig/thr_tcdrain.c thread/thr_tcdrain.c *** thread.orig/thr_tcdrain.c Mon Dec 8 18:20:56 2003 --- thread/thr_tcdrain.c Mon Jun 7 18:05:54 2004 *************** *** 35,42 **** extern int __tcdrain(int); - __weak_reference(_tcdrain, tcdrain); - int _tcdrain(int fd) { --- 35,40 ---- *************** _tcdrain(int fd) *** 49,51 **** --- 47,51 ---- return (ret); } + + __strong_reference(_tcdrain, tcdrain); diff -c3pr thread.orig/thr_vfork.c thread/thr_vfork.c *** thread.orig/thr_vfork.c Mon Apr 9 21:19:20 2001 --- thread/thr_vfork.c Mon Jun 7 18:06:04 2004 *************** *** 3,12 **** */ #include - __weak_reference(_vfork, vfork); - int _vfork(void) { return (fork()); } --- 3,12 ---- */ #include int _vfork(void) { return (fork()); } + + __strong_reference(_vfork, vfork); diff -c3pr thread.orig/thr_wait.c thread/thr_wait.c *** thread.orig/thr_wait.c Mon Dec 8 18:20:56 2003 --- thread/thr_wait.c Mon Jun 7 18:06:12 2004 *************** *** 34,41 **** extern int __wait(int *); - __weak_reference(_wait, wait); - pid_t _wait(int *istat) { --- 34,39 ---- *************** _wait(int *istat) *** 48,50 **** --- 46,50 ---- return ret; } + + __strong_reference(_wait, wait); diff -c3pr thread.orig/thr_wait4.c thread/thr_wait4.c *** thread.orig/thr_wait4.c Mon Dec 8 18:20:56 2003 --- thread/thr_wait4.c Mon Jun 7 18:06:20 2004 *************** *** 41,48 **** #include "thr_private.h" - __weak_reference(__wait4, wait4); - pid_t __wait4(pid_t pid, int *istat, int options, struct rusage *rusage) { --- 41,46 ---- *************** __wait4(pid_t pid, int *istat, int optio *** 55,57 **** --- 53,57 ---- return ret; } + + __strong_reference(__wait4, wait4); diff -c3pr thread.orig/thr_waitpid.c thread/thr_waitpid.c *** thread.orig/thr_waitpid.c Mon Dec 8 18:20:56 2003 --- thread/thr_waitpid.c Mon Jun 7 18:06:29 2004 *************** *** 36,43 **** extern int __waitpid(pid_t, int *, int); - __weak_reference(_waitpid, waitpid); - pid_t _waitpid(pid_t wpid, int *status, int options) { --- 36,41 ---- *************** _waitpid(pid_t wpid, int *status, int op *** 50,52 **** --- 48,52 ---- return ret; } + + __strong_reference(_waitpid, waitpid); diff -c3pr thread.orig/thr_write.c thread/thr_write.c *** thread.orig/thr_write.c Mon Dec 8 18:20:56 2003 --- thread/thr_write.c Mon Jun 7 18:06:37 2004 *************** *** 40,47 **** #include #include "thr_private.h" - __weak_reference(__write, write); - ssize_t __write(int fd, const void *buf, size_t nbytes) { --- 40,45 ---- *************** __write(int fd, const void *buf, size_t *** 54,56 **** --- 52,56 ---- return ret; } + + __strong_reference(__write, write); diff -c3pr thread.orig/thr_writev.c thread/thr_writev.c *** thread.orig/thr_writev.c Mon Dec 8 18:20:56 2003 --- thread/thr_writev.c Mon Jun 7 18:06:45 2004 *************** *** 42,49 **** #include #include "thr_private.h" - __weak_reference(__writev, writev); - ssize_t __writev(int fd, const struct iovec *iov, int iovcnt) { --- 42,47 ---- *************** __writev(int fd, const struct iovec *iov *** 56,58 **** --- 54,58 ---- return ret; } + + __strong_reference(__writev, writev); diff -c3pr thread.orig/thr_yield.c thread/thr_yield.c *** thread.orig/thr_yield.c Sun Aug 17 20:58:29 2003 --- thread/thr_yield.c Mon Jun 7 18:06:55 2004 *************** *** 34,42 **** #include #include "thr_private.h" - __weak_reference(_sched_yield, sched_yield); - __weak_reference(_pthread_yield, pthread_yield); - int _sched_yield(void) { --- 34,39 ---- *************** _pthread_yield(void) *** 71,73 **** --- 68,73 ---- /* Schedule the next thread: */ _thr_sched_switch(curthread); } + + __strong_reference(_sched_yield, sched_yield); + __strong_reference(_pthread_yield, pthread_yield); From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 8 03:19:25 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE20F16A4CE; Tue, 8 Jun 2004 03:19:25 +0000 (GMT) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45EA743D2F; Tue, 8 Jun 2004 03:19:25 +0000 (GMT) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (210.50.40.174) by smtp01.syd.iprimus.net.au (7.0.024) id 40B7A0DA002EB19C; Tue, 8 Jun 2004 13:19:23 +1000 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id 567F841CE; Tue, 8 Jun 2004 13:21:11 +1000 (EST) Date: Tue, 8 Jun 2004 13:21:11 +1000 From: Tim Robbins To: Sean McNeil Message-ID: <20040608032111.GA43718@cat.robbins.dropbear.id.au> References: <1086663455.1258.79.camel@server.mcneil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1086663455.1258.79.camel@server.mcneil.com> User-Agent: Mutt/1.4.1i cc: freebsd-current@freebsd.org cc: freebsd-gnome@freebsd.org cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 03:19:26 -0000 On Mon, Jun 07, 2004 at 07:57:35PM -0700, Sean McNeil wrote: > > Up front, I'd like to make a few apologies: > > 1) I am sorry for the length of this email. > 2) Although some very valid opinions have been expressed, I respectfully > have to disagree. This email will hopefully strengthen my position. > > The problem: > > (If you just want kse threads to work for you properly, just apply the > patch at the end of this email and try it out). > > kse threads on amd64 doesn't work with gnome. It crashes applications > here and there. gnome-terminal is essentially unusable. > > I strongly believe this to be a binding issue. I've examined rtld and > I'm satisfied that it is behaving appropriately, so I took a long hard > look at how FreeBSD has implemented the pthread interface, how it is > being used, and how people expect it to behave. [...] Your patch looks useful in its own right, but GNOME, Firefox, Mozilla and XMMS have not crashed once for me since I fixed context restoring in libpthread on amd64. Strong references cannot possibly make the old version of context.S work correctly. I would be interested in hearing whether you still have problems with libpthread and GNOME after updating your system, both with and without nss_ldap. Tim From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 8 03:28:48 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A816116A4CE for ; Tue, 8 Jun 2004 03:28:48 +0000 (GMT) Received: from simmts8-srv.bellnexxia.net (simmts8.bellnexxia.net [206.47.199.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id E84B143D49 for ; Tue, 8 Jun 2004 03:28:47 +0000 (GMT) (envelope-from K.Farmer@sympatico.ca) Received: from kfarmerhome ([69.156.57.126]) by simmts8-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with SMTP id <20040608032840.BKSK28685.simmts8-srv.bellnexxia.net@kfarmerhome> for ; Mon, 7 Jun 2004 23:28:40 -0400 Message-ID: <000501c44d08$b0d1e7c0$6702a8c0@kfarmerhome> From: "Kelvin Farmer" To: Date: Mon, 7 Jun 2004 23:28:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: Asus K8V - onboard raid issue, 2nd drive not present X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 03:28:48 -0000 I have an Asus K8V SE DLX (VIA K8T800) motherboard with an Athlon64 cpu and am trying to set up a 2 disk raid on it's builtin promise PDC20378 raid controller. MS Windows XP see & installs on this raid setup fine, but FreeBSD 5.2.1 release doesn't seem to see the second disk (another 40gb Maxtor 6E040L0) in the raid properly, ie "disk1 DOWN no device found for this disk". seemingly relevant part of dmesg below: ar: FreeBSD check1 failed ata4-master: pio=0x0c wdma=0x22 udma=0x46 cable=40pin ata4-master: setting PIO4 on Promise PDC20378 chip ata4-master: setting UDMA133 on Promise PDC20378 chip GEOM: create disk ad8 dp=0xffffff003c9790a0 ad8: ATA-7 disk at ata4-master ad8: 39205MB (80293248 sectors), 79656 C, 16 H, 63 S, 512 B ad8: 16 secs/int, 1 depth queue, UDMA133 lun 0 magic_0 0x00000000 magic_1 0x00000000 flags 0x1101 1101 total_disks 2 generation 1 width 2 heads 255 sectors 63 cylinders 9996 total_sectors 160586240 interleave 128 reserved 63 offset 0 disk 0: flags = 0x0b b ad8 sectors 80293185 disk 1: flags = 0x0a a sectors 0 ar0: ERROR - array broken GEOM: create disk ar0 dp=0xffffff003c8e4670 ar0: 78411MB [9996/255/63] status: BROKEN subdisks: disk0 READY on ad8 at ata4-master disk1 DOWN no device found for this disk Any suggestions? anyone else using this hardware with sucess ? Thanks Kelvin Farmer Snr Network Analyst Cdn Institute for Health Information Ottawa, ON Canada. From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 8 03:33:11 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7783816A4CE; Tue, 8 Jun 2004 03:33:11 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B3FA43D53; Tue, 8 Jun 2004 03:33:11 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 0A710FD06C; Mon, 7 Jun 2004 20:33:11 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00675-05; Mon, 7 Jun 2004 20:33:10 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 90B6EFD01A; Mon, 7 Jun 2004 20:33:10 -0700 (PDT) From: Sean McNeil To: Tim Robbins In-Reply-To: <20040608032111.GA43718@cat.robbins.dropbear.id.au> References: <1086663455.1258.79.camel@server.mcneil.com> <20040608032111.GA43718@cat.robbins.dropbear.id.au> Content-Type: text/plain Message-Id: <1086665590.1817.3.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 07 Jun 2004 20:33:10 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-current@freebsd.org cc: freebsd-gnome@freebsd.org cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 03:33:11 -0000 On Mon, 2004-06-07 at 20:21, Tim Robbins wrote: > On Mon, Jun 07, 2004 at 07:57:35PM -0700, Sean McNeil wrote: > > > > > Up front, I'd like to make a few apologies: > > > > 1) I am sorry for the length of this email. > > 2) Although some very valid opinions have been expressed, I respectfully > > have to disagree. This email will hopefully strengthen my position. > > > > The problem: > > > > (If you just want kse threads to work for you properly, just apply the > > patch at the end of this email and try it out). > > > > kse threads on amd64 doesn't work with gnome. It crashes applications > > here and there. gnome-terminal is essentially unusable. > > > > I strongly believe this to be a binding issue. I've examined rtld and > > I'm satisfied that it is behaving appropriately, so I took a long hard > > look at how FreeBSD has implemented the pthread interface, how it is > > being used, and how people expect it to behave. > [...] > > Your patch looks useful in its own right, but GNOME, Firefox, Mozilla > and XMMS have not crashed once for me since I fixed context restoring in > libpthread on amd64. Strong references cannot possibly make the old > version of context.S work correctly. > > I would be interested in hearing whether you still have problems with > libpthread and GNOME after updating your system, both with and without > nss_ldap. Great, Tim! I did indeed get this fix when testing my changes. The patch I posted still has some redeeming value, but yours was the key to gnome stability for me as well. Sean From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 8 04:32:05 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 510A016A4CE; Tue, 8 Jun 2004 04:32:05 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBFA743D5C; Tue, 8 Jun 2004 04:32:04 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i584W1tD015956; Tue, 8 Jun 2004 00:32:04 -0400 (EDT) Date: Tue, 8 Jun 2004 00:32:01 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086663455.1258.79.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: freebsd-gnome@freebsd.org cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 04:32:05 -0000 On Mon, 7 Jun 2004, Sean McNeil wrote: > > Up front, I'd like to make a few apologies: > > 1) I am sorry for the length of this email. > 2) Although some very valid opinions have been expressed, I respectfully > have to disagree. This email will hopefully strengthen my position. Please stop spamming multiple lists. No, I don't want to litter all our thread libraries with strong references. As I've said before, build your shared libraries correctly so they don't bring in the threads library. -- Dan Eischen From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 8 04:48:46 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF95416A4D5; Tue, 8 Jun 2004 04:48:46 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0A3243D45; Tue, 8 Jun 2004 04:48:45 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.10/8.12.10) id i584mjND047596; Mon, 7 Jun 2004 23:48:45 -0500 (CDT) (envelope-from dan) Date: Mon, 7 Jun 2004 23:48:45 -0500 From: Dan Nelson To: Daniel Eischen Message-ID: <20040608044844.GA89198@dan.emsphone.com> References: <1086663455.1258.79.camel@server.mcneil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 5.2-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: freebsd-amd64@freebsd.org cc: freebsd-current@freebsd.org cc: Sean McNeil cc: freebsd-gnome@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 04:48:46 -0000 In the last episode (Jun 08), Daniel Eischen said: > No, I don't want to litter all our thread libraries with strong > references. As I've said before, build your shared libraries > correctly so they don't bring in the threads library. A good addition to bsd.port.mk, right next to the "possible network server" etc checks, might be to run ldd on all installed shared libraries and print a warning if any threads libraries show up. There are a huge number of ports that install shlibs linked to libpthreads. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 8 05:13:37 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D791F16A4D0; Tue, 8 Jun 2004 05:13:37 +0000 (GMT) Received: from creme-brulee.marcuscom.com (rrcs-midsouth-24-172-16-118.biz.rr.com [24.172.16.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3106143D46; Tue, 8 Jun 2004 05:13:37 +0000 (GMT) (envelope-from marcus@marcuscom.com) Received: from [192.168.1.4] (shumai.marcuscom.com [192.168.1.4]) i585CdRw096687; Tue, 8 Jun 2004 01:12:39 -0400 (EDT) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: Daniel Eischen In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-4faQEVN185PHyZKJ00vz" Organization: MarcusCom, Inc. Message-Id: <1086671609.18374.18.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 08 Jun 2004 01:13:29 -0400 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on creme-brulee.marcuscom.com cc: freebsd-amd64@freebsd.org cc: freebsd-current@freebsd.org cc: Sean McNeil cc: freebsd-gnome@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 05:13:38 -0000 --=-4faQEVN185PHyZKJ00vz Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2004-06-08 at 00:32, Daniel Eischen wrote: > On Mon, 7 Jun 2004, Sean McNeil wrote: >=20 > >=20 > > Up front, I'd like to make a few apologies: > >=20 > > 1) I am sorry for the length of this email. > > 2) Although some very valid opinions have been expressed, I respectfull= y > > have to disagree. This email will hopefully strengthen my position. >=20 > Please stop spamming multiple lists. >=20 > No, I don't want to litter all our thread libraries with strong reference= s. > As I've said before, build your shared libraries correctly so they don't > bring in the threads library. In order to do this, I'm a strong proponent of making -pthread the default PTHREAD_LIBS from 4.X and 5.X. This will do the right thing in all cases, and reduces diffs among branches. What is keeping this from happening from a threading standpoint? Joe --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-4faQEVN185PHyZKJ00vz Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAxUr5b2iPiv4Uz4cRAm8EAKCNndWyv3S5K6+bTsCc+F6MkQIyJgCgksgJ 4S+uSdmI4eKIGyXUUEbBDcs= =1kPV -----END PGP SIGNATURE----- --=-4faQEVN185PHyZKJ00vz-- From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 8 05:21:42 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A1A316A4CE; Tue, 8 Jun 2004 05:21:42 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id C833543D54; Tue, 8 Jun 2004 05:21:41 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from freebsd.org (junior-wifi.samsco.home [192.168.0.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i585NvTj001259; Mon, 7 Jun 2004 23:23:58 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <40C54CC4.8090602@freebsd.org> Date: Mon, 07 Jun 2004 23:21:08 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Marcus Clarke References: <1086671609.18374.18.camel@shumai.marcuscom.com> In-Reply-To: <1086671609.18374.18.camel@shumai.marcuscom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-amd64@freebsd.org cc: freebsd-gnome@freebsd.org cc: freebsd-threads@freebsd.org cc: freebsd-current@freebsd.org cc: Daniel Eischen cc: Sean McNeil Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 05:21:42 -0000 Joe Marcus Clarke wrote: > On Tue, 2004-06-08 at 00:32, Daniel Eischen wrote: > >>On Mon, 7 Jun 2004, Sean McNeil wrote: >> >> >>>Up front, I'd like to make a few apologies: >>> >>>1) I am sorry for the length of this email. >>>2) Although some very valid opinions have been expressed, I respectfully >>>have to disagree. This email will hopefully strengthen my position. >> >>Please stop spamming multiple lists. >> >>No, I don't want to litter all our thread libraries with strong references. >>As I've said before, build your shared libraries correctly so they don't >>bring in the threads library. > > > In order to do this, I'm a strong proponent of making -pthread the > default PTHREAD_LIBS from 4.X and 5.X. This will do the right thing in > all cases, and reduces diffs among branches. What is keeping this from > happening from a threading standpoint? > > Joe > If you're going to change default behaviour like this then you need to do it before 5.3 and live with the change for the entire life of 5.x. I oppose changing it in 4.x. Scott From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 8 05:24:56 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A5D816A4CE; Tue, 8 Jun 2004 05:24:56 +0000 (GMT) Received: from creme-brulee.marcuscom.com (rrcs-midsouth-24-172-16-118.biz.rr.com [24.172.16.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89D5343D45; Tue, 8 Jun 2004 05:24:55 +0000 (GMT) (envelope-from marcus@marcuscom.com) Received: from [192.168.1.4] (shumai.marcuscom.com [192.168.1.4]) i585Nvel096804; Tue, 8 Jun 2004 01:23:57 -0400 (EDT) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: Scott Long In-Reply-To: <40C54CC4.8090602@freebsd.org> References: <1086671609.18374.18.camel@shumai.marcuscom.com> <40C54CC4.8090602@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-BHBN6it8T3voSfmtqZO4" Organization: MarcusCom, Inc. Message-Id: <1086672287.18374.22.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 08 Jun 2004 01:24:47 -0400 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on creme-brulee.marcuscom.com cc: freebsd-amd64@freebsd.org cc: freebsd-gnome@freebsd.org cc: freebsd-threads@freebsd.org cc: freebsd-current@freebsd.org cc: Daniel Eischen cc: Sean McNeil Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 05:24:56 -0000 --=-BHBN6it8T3voSfmtqZO4 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2004-06-08 at 01:21, Scott Long wrote: > Joe Marcus Clarke wrote: > > On Tue, 2004-06-08 at 00:32, Daniel Eischen wrote: > >=20 > >>On Mon, 7 Jun 2004, Sean McNeil wrote: > >> > >> > >>>Up front, I'd like to make a few apologies: > >>> > >>>1) I am sorry for the length of this email. > >>>2) Although some very valid opinions have been expressed, I respectful= ly > >>>have to disagree. This email will hopefully strengthen my position. > >> > >>Please stop spamming multiple lists. > >> > >>No, I don't want to litter all our thread libraries with strong referen= ces. > >>As I've said before, build your shared libraries correctly so they don'= t > >>bring in the threads library. > >=20 > >=20 > > In order to do this, I'm a strong proponent of making -pthread the > > default PTHREAD_LIBS from 4.X and 5.X. This will do the right thing in > > all cases, and reduces diffs among branches. What is keeping this from > > happening from a threading standpoint? > >=20 > > Joe > >=20 >=20 > If you're going to change default behaviour like this then you need to > do it before 5.3 and live with the change for the entire life of 5.x. > I oppose changing it in 4.x. Right, this would only be a change for 5.X, and would make it identical to 4.X. -pthread works for 5.X right now, and will link executables to libpthread. Shared objects will only use libpthread to resolve symbols at link-time. Joe >=20 > Scott --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-BHBN6it8T3voSfmtqZO4 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAxU2fb2iPiv4Uz4cRAqf5AJ9SfU4UTuiLp7I2I3Etf47S465qogCfRYdO O0S9uJCFTifzADBw6cK3euE= =IIbB -----END PGP SIGNATURE----- --=-BHBN6it8T3voSfmtqZO4-- From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 8 06:38:51 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A7F816A4CE; Tue, 8 Jun 2004 06:38:51 +0000 (GMT) Received: from mail.takas.lt (mail-src.takas.lt [212.59.31.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id 221A043D46; Tue, 8 Jun 2004 06:38:47 +0000 (GMT) (envelope-from marcus@marcuscom.com) Received: from mail pickup service by mail.takas.lt with Microsoft SMTPSVC; Tue, 8 Jun 2004 09:38:29 +0300 Received: from mx2.freebsd.org ([216.136.204.119]) by mail.takas.lt with Microsoft SMTPSVC(5.0.2195.6713); Tue, 8 Jun 2004 08:14:06 +0300 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id F21B556C90; Tue, 8 Jun 2004 05:13:47 +0000 (GMT) (envelope-from owner-freebsd-current@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 6325216A4D6; Tue, 8 Jun 2004 05:13:47 +0000 (GMT) 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 D791F16A4D0; Tue, 8 Jun 2004 05:13:37 +0000 (GMT) Received: from creme-brulee.marcuscom.com (rrcs-midsouth-24-172-16-118.biz.rr.com [24.172.16.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3106143D46; Tue, 8 Jun 2004 05:13:37 +0000 (GMT) (envelope-from marcus@marcuscom.com) Received: from [192.168.1.4] (shumai.marcuscom.com [192.168.1.4]) i585CdRw096687; Tue, 8 Jun 2004 01:12:39 -0400 (EDT) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: Daniel Eischen In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-4faQEVN185PHyZKJ00vz" Organization: MarcusCom, Inc. Message-Id: <1086671609.18374.18.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 08 Jun 2004 01:13:29 -0400 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on creme-brulee.marcuscom.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-current@freebsd.org Errors-To: owner-freebsd-current@freebsd.org X-OriginalArrivalTime: 08 Jun 2004 05:14:06.0507 (UTC) FILETIME=[6C04FFB0:01C44D17] cc: freebsd-current@freebsd.org cc: freebsd-gnome@freebsd.org cc: Sean McNeil cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-amd64@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 06:38:51 -0000 --=-4faQEVN185PHyZKJ00vz Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2004-06-08 at 00:32, Daniel Eischen wrote: > On Mon, 7 Jun 2004, Sean McNeil wrote: >=20 > >=20 > > Up front, I'd like to make a few apologies: > >=20 > > 1) I am sorry for the length of this email. > > 2) Although some very valid opinions have been expressed, I respectfull= y > > have to disagree. This email will hopefully strengthen my position. >=20 > Please stop spamming multiple lists. >=20 > No, I don't want to litter all our thread libraries with strong reference= s. > As I've said before, build your shared libraries correctly so they don't > bring in the threads library. In order to do this, I'm a strong proponent of making -pthread the default PTHREAD_LIBS from 4.X and 5.X. This will do the right thing in all cases, and reduces diffs among branches. What is keeping this from happening from a threading standpoint? Joe --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-4faQEVN185PHyZKJ00vz Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAxUr5b2iPiv4Uz4cRAm8EAKCNndWyv3S5K6+bTsCc+F6MkQIyJgCgksgJ 4S+uSdmI4eKIGyXUUEbBDcs= =1kPV -----END PGP SIGNATURE----- --=-4faQEVN185PHyZKJ00vz-- From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 8 07:27:10 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1889116A4CE; Tue, 8 Jun 2004 07:27:10 +0000 (GMT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4C2143D45; Tue, 8 Jun 2004 07:27:09 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (adsl-63-207-60-35.dsl.lsan03.pacbell.net [63.207.60.35])i587R7qE022779; Tue, 8 Jun 2004 03:27:07 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id D6D5651955; Tue, 8 Jun 2004 00:27:06 -0700 (PDT) Date: Tue, 8 Jun 2004 00:27:06 -0700 From: Kris Kennaway To: Dan Nelson Message-ID: <20040608072706.GA82243@xor.obsecurity.org> References: <1086663455.1258.79.camel@server.mcneil.com> <20040608044844.GA89198@dan.emsphone.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: <20040608044844.GA89198@dan.emsphone.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-amd64@freebsd.org cc: freebsd-gnome@freebsd.org cc: freebsd-threads@freebsd.org cc: freebsd-current@freebsd.org cc: Daniel Eischen cc: Sean McNeil Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 07:27:10 -0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 07, 2004 at 11:48:45PM -0500, Dan Nelson wrote: > In the last episode (Jun 08), Daniel Eischen said: > > No, I don't want to litter all our thread libraries with strong > > references. As I've said before, build your shared libraries > > correctly so they don't bring in the threads library. >=20 > A good addition to bsd.port.mk, right next to the "possible network > server" etc checks, might be to run ldd on all installed shared > libraries and print a warning if any threads libraries show up. There > are a huge number of ports that install shlibs linked to libpthreads. Some of these are probably correct, in that the library started using libpthreads internally and there are a large number of clients that would otherwise need to be changed to link to that library. Kris --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAxWpKWry0BWjoQKURAn+6AJ46khXPmJulpz485nM4Xb2p43vargCdFEma OpAqGmYFBmYWVAdxb7FFKgk= =yXEK -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 8 10:40:31 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50D2C16A4CE for ; Tue, 8 Jun 2004 10:40:31 +0000 (GMT) Received: from freebee.digiware.nl (dsl390.iae.nl [212.61.63.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0926C43D54 for ; Tue, 8 Jun 2004 10:40:30 +0000 (GMT) (envelope-from wjw@withagen.nl) Received: from dual (dual [212.61.27.71]) by freebee.digiware.nl (8.12.10/8.12.10) with SMTP id i58AZS67088324 for ; Tue, 8 Jun 2004 12:35:29 +0200 (CEST) (envelope-from wjw@withagen.nl) Message-ID: <0bb701c44d44$5ba32570$471b3dd4@dual> From: "Willem Jan Withagen" To: Date: Tue, 8 Jun 2004 12:35:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: Getting kernel dumps X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 10:40:31 -0000 After fixing user core dumps > 2 Gb, I'm now in search of getting my kerneldumps to work..... opteron# uname -a FreeBSD opteron.digiware.nl 5.2-CURRENT FreeBSD 5.2-CURRENT #17: Fri Jun 4 15:2 9:43 CEST 2004 wjw@opteron.digiware.nl:/usr/obj/home2/src/sys/OPTERON.amd64 amd64 This is what I do: ---------------- ctrl-alt-esc db> call doadump Dumping 2046 MB Dump failed. Partition too small. 0x23 ---------------- Which is sort of bogus since the swappartition is "only" 5GB and there's only 2 GB of memory in the box. Trying to get a panic: ----------------- db> panic panic: from debugger at line 453 in file /home2/src/sys/ddb/db_command.c cpuid = 1; Stack backtrace: backtrace() at backtrace+0x17 __panic() at __panic+0x1e4 db_panic() at db_panic+0x1e db_command() at db_command+0x24e db_command_loop() at db_command_loop+0x88 db_trap() at db_trap+0xb5 kdb_trap() at kdb_trap+0x151 trap() at trap+0x3bd calltrap() at calltrap+0x5 --- trap 0x3, rip = 0xffffffff80393d45, rsp = 0xffffffffb19d4ae0, rbp = 0xffffff ffb19d4b00 --- Debugger() at Debugger+0x4d scgetc() at scgetc+0x43f sckbdevent() at sckbdevent+0x201 atkbd_intr() at atkbd_intr+0x26 atkbd_isa_intr() at atkbd_isa_intr+0x1a ithread_loop() at ithread_loop+0x229 fork_exit() at fork_exit+0xe5 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffb19d4d00, rbp = 0 --- boot() called on cpu#1 syncing disks, buffers remaining... panic: pmap_invalidate_range: interrupts dis abled at line 654 in file /home2/src/sys/amd64/amd64/pmap.ccpuid = 1; boot() called on cpu#1 Uptime: 3d13h29m59s ------------------- And a hard reset is required..... 2 questions: 1) Are others with amd64/2Gb memory able to get kerneldumps??? 2) Where should I start looking to get thigs fixed.... --WjW From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 8 10:46:44 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3447716A4CE for ; Tue, 8 Jun 2004 10:46:44 +0000 (GMT) Received: from freebee.digiware.nl (dsl390.iae.nl [212.61.63.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E7F043D4C for ; Tue, 8 Jun 2004 10:46:43 +0000 (GMT) (envelope-from wjw@withagen.nl) Received: from dual (dual [212.61.27.71]) by freebee.digiware.nl (8.12.10/8.12.10) with SMTP id i58Afh67088463 for ; Tue, 8 Jun 2004 12:41:43 +0200 (CEST) (envelope-from wjw@withagen.nl) Message-ID: <0bbd01c44d45$3ac110f0$471b3dd4@dual> From: "Willem Jan Withagen" To: Date: Tue, 8 Jun 2004 12:42:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: Strange time call X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 10:46:44 -0000 When rebooting I get this.... Starting moused:Expensive timeout(9) function: 0xffffffff803c256c(0xffffff0000a8c000) 0.010391544 s This grepped from the console, so there does not have to be a disctinct relation between moused and the timeout. But it is every time in the exact same location.... 0xffffffff803c256c looks again like a 32/64 conversion error.... Where the other one originates from is something to look for --WjW From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 8 11:53:39 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4652F16A4CE for ; Tue, 8 Jun 2004 11:53:39 +0000 (GMT) Received: from freebee.digiware.nl (dsl390.iae.nl [212.61.63.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 558C443D58 for ; Tue, 8 Jun 2004 11:53:38 +0000 (GMT) (envelope-from wjw@withagen.nl) Received: from dual (dual [212.61.27.71]) by freebee.digiware.nl (8.12.10/8.12.10) with SMTP id i58BmT67089693; Tue, 8 Jun 2004 13:48:29 +0200 (CEST) (envelope-from wjw@withagen.nl) Message-ID: <0bf701c44d4e$8ed79f20$471b3dd4@dual> From: "Willem Jan Withagen" To: "Willem Jan Withagen" , References: <0bb701c44d44$5ba32570$471b3dd4@dual> Date: Tue, 8 Jun 2004 13:48:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: Re: Getting kernel dumps X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 11:53:39 -0000 > After fixing user core dumps > 2 Gb, I'm now in search of getting my kerneldumps > to work..... > > opteron# uname -a > FreeBSD opteron.digiware.nl 5.2-CURRENT FreeBSD 5.2-CURRENT #17: Fri Jun 4 15:2 > 9:43 CEST 2004 wjw@opteron.digiware.nl:/usr/obj/home2/src/sys/OPTERON.amd64 > amd64 > > > This is what I do: > ---------------- > ctrl-alt-esc > > db> call doadump > Dumping 2046 MB > > Dump failed. Partition too small. > 0x23 > ---------------- > > Which is sort of bogus since the swappartition is "only" 5GB and there's only > 2 GB of memory in the box. Pilot error in this one..... dumpon /dev/ad0s2b was my friend I'll send a PR to take this as aspecific example so other do not get burnt as well. --WjW From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 8 12:30:55 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68A7416A4CE for ; Tue, 8 Jun 2004 12:30:55 +0000 (GMT) Received: from freebee.digiware.nl (dsl390.iae.nl [212.61.63.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id C355843D4C for ; Tue, 8 Jun 2004 12:30:54 +0000 (GMT) (envelope-from wjw@withagen.nl) Received: from dual (dual [212.61.27.71]) by freebee.digiware.nl (8.12.10/8.12.10) with SMTP id i58CPo67090691 for ; Tue, 8 Jun 2004 14:25:50 +0200 (CEST) (envelope-from wjw@withagen.nl) Message-ID: <0c3d01c44d53$c1603ab0$471b3dd4@dual> From: "Willem Jan Withagen" To: References: <0bb701c44d44$5ba32570$471b3dd4@dual> <0bf701c44d4e$8ed79f20$471b3dd4@dual> Date: Tue, 8 Jun 2004 14:25:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: Re: Getting kernel dumps X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 12:30:55 -0000 > > After fixing user core dumps > 2 Gb, I'm now in search of getting my > kerneldumps > > to work..... > > > > opteron# uname -a > > FreeBSD opteron.digiware.nl 5.2-CURRENT FreeBSD 5.2-CURRENT #17: Fri Jun 4 > 15:2 > > 9:43 CEST 2004 > wjw@opteron.digiware.nl:/usr/obj/home2/src/sys/OPTERON.amd64 > > amd64 > > > > > > This is what I do: > > ---------------- > > ctrl-alt-esc > > > > db> call doadump > > Dumping 2046 MB > > > > Dump failed. Partition too small. > > 0x23 > > ---------------- > > > > Which is sort of bogus since the swappartition is "only" 5GB and there's only > > 2 GB of memory in the box. > > Pilot error in this one..... > > dumpon /dev/ad0s2b was my friend > > I'll send a PR to take this as aspecific example so other do not get burnt as > well. I now have a dump, but it does not seem to be correct...... ======== opteron# savecore -v checking for kernel dump on device /dev/ad0s2b mediasize = 5368709120 sectorsize = 512 savecore: parity error on last dump header on /dev/ad0s2b savecore: unsaved dumps found but not saved ======== Is this because I 'call doadump' which is not appropriate??? Or are the headers really mangled... And then why?? --WjW From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 8 13:10:18 2004 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D39A16A4CE for ; Tue, 8 Jun 2004 13:10:18 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C7B143D55 for ; Tue, 8 Jun 2004 13:10:18 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i58DAHlF015210 for ; Tue, 8 Jun 2004 13:10:17 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i58DAHD1015209; Tue, 8 Jun 2004 13:10:17 GMT (envelope-from gnats) Resent-Date: Tue, 8 Jun 2004 13:10:17 GMT Resent-Message-Id: <200406081310.i58DAHD1015209@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Willem Jan Withagen Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD0C016A4CE for ; Tue, 8 Jun 2004 13:03:26 +0000 (GMT) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7EEA43D45 for ; Tue, 8 Jun 2004 13:03:26 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.12.11/8.12.11) with ESMTP id i58D3Hx6050821 for ; Tue, 8 Jun 2004 13:03:17 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.12.11/8.12.11/Submit) id i58D3HKu050819; Tue, 8 Jun 2004 13:03:17 GMT (envelope-from nobody) Message-Id: <200406081303.i58D3HKu050819@www.freebsd.org> Date: Tue, 8 Jun 2004 13:03:17 GMT From: Willem Jan Withagen To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Subject: amd64/67712: Extra informal text when trying to dump but dumpdev is not set. X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 13:10:18 -0000 >Number: 67712 >Category: amd64 >Synopsis: Extra informal text when trying to dump but dumpdev is not set. >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Tue Jun 08 13:10:17 GMT 2004 >Closed-Date: >Last-Modified: >Originator: Willem Jan Withagen >Release: 5.2-CURRENT >Organization: Digiware >Environment: FreeBSD opteron.digiware.nl 5.2-CURRENT FreeBSD 5.2-CURRENT #22: Tue Jun 8 13:44:17 CEST 2004 wjw@opteron.digiware.nl:/usr/obj/home2/src/sys/OPTERON.amd64 amd64 >Description: Calling doadump without dumpdev set claims that the partition was too small. Well it worse, it did not exist. This patch gives a better diagnostic. It might also be usefull with i386 ea. >How-To-Repeat: >Fix: --- sys/amd64/amd64/dump_machdep.c.org Tue Jun 8 14:56:49 2004 +++ sys/amd64/amd64/dump_machdep.c Tue Jun 8 14:56:00 2004 @@ -85,6 +85,8 @@ if (di->mediasize < Maxmem * (off_t)PAGE_SIZE + sizeof kdh * 2 + 64*1024) { printf("\nDump failed. Partition too small.\n"); + if (di->mediasize == 0 ) + printf("Partition to dump on is not set. See dumpon(8)\n"); return; } dumplo = di->mediaoffset + di->mediasize - Maxmem * (off_t)PAGE_SIZE; >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 8 15:30:22 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 5900116A4D1; Tue, 8 Jun 2004 15:30:22 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.12.11/8.12.11) with ESMTP id i58FULKt045926; Tue, 8 Jun 2004 11:30:21 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.12.11/8.12.11/Submit) id i58FUF4V045925; Tue, 8 Jun 2004 11:30:15 -0400 (EDT) (envelope-from green) Date: Tue, 8 Jun 2004 11:30:14 -0400 From: Brian Feldman To: Kris Kennaway Message-ID: <20040608153014.GE23083@green.homeunix.org> References: <1086663455.1258.79.camel@server.mcneil.com> <20040608044844.GA89198@dan.emsphone.com> <20040608072706.GA82243@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040608072706.GA82243@xor.obsecurity.org> User-Agent: Mutt/1.5.6i cc: freebsd-amd64@freebsd.org cc: freebsd-gnome@freebsd.org cc: Dan Nelson cc: freebsd-threads@freebsd.org cc: freebsd-current@freebsd.org cc: Sean McNeil Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 15:30:22 -0000 On Tue, Jun 08, 2004 at 12:27:06AM -0700, Kris Kennaway wrote: > On Mon, Jun 07, 2004 at 11:48:45PM -0500, Dan Nelson wrote: > > In the last episode (Jun 08), Daniel Eischen said: > > > No, I don't want to litter all our thread libraries with strong > > > references. As I've said before, build your shared libraries > > > correctly so they don't bring in the threads library. > > > > A good addition to bsd.port.mk, right next to the "possible network > > server" etc checks, might be to run ldd on all installed shared > > libraries and print a warning if any threads libraries show up. There > > are a huge number of ports that install shlibs linked to libpthreads. > > Some of these are probably correct, in that the library started using > libpthreads internally and there are a large number of clients that > would otherwise need to be changed to link to that library. In this case, Berkeley DB 4.2 actually doesn't even compile in pthreads support (which it would use exclusively for mutexes); since it compiles in "test-and-set" mutex support, the linking to -lpthread is 100% bogus. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 8 15:45:12 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9287F16A4CE; Tue, 8 Jun 2004 15:45:12 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45BEB43D55; Tue, 8 Jun 2004 15:45:12 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.10/8.12.10) id i58FjB58020252; Tue, 8 Jun 2004 10:45:11 -0500 (CDT) (envelope-from dan) Date: Tue, 8 Jun 2004 10:45:11 -0500 From: Dan Nelson To: Kris Kennaway Message-ID: <20040608154510.GB89198@dan.emsphone.com> References: <1086663455.1258.79.camel@server.mcneil.com> <20040608044844.GA89198@dan.emsphone.com> <20040608072706.GA82243@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline In-Reply-To: <20040608072706.GA82243@xor.obsecurity.org> X-OS: FreeBSD 5.2-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: freebsd-amd64@freebsd.org cc: freebsd-gnome@freebsd.org cc: freebsd-threads@freebsd.org cc: freebsd-current@freebsd.org cc: Daniel Eischen cc: Sean McNeil Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 15:45:12 -0000 --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In the last episode (Jun 08), Kris Kennaway said: > On Mon, Jun 07, 2004 at 11:48:45PM -0500, Dan Nelson wrote: > > In the last episode (Jun 08), Daniel Eischen said: > > > No, I don't want to litter all our thread libraries with strong > > > references. As I've said before, build your shared libraries > > > correctly so they don't bring in the threads library. > > > > A good addition to bsd.port.mk, right next to the "possible network > > server" etc checks, might be to run ldd on all installed shared > > libraries and print a warning if any threads libraries show up. There > > are a huge number of ports that install shlibs linked to libpthreads. > > Some of these are probably correct, in that the library started using > libpthreads internally and there are a large number of clients that > would otherwise need to be changed to link to that library. I don't think you can have it both ways, though. The rule is either "pthreads-using shared libraries should pull in a pthreads lib themselves" or "programs wanting to link to pthreads-using shared libraries should link with a pthreads lib". Attached are patches to add this check to the security-check target. Ideally they would be checked separately or flagged as something other than security problems, but that would require copying security-check.awk and a larger diff.. -- Dan Nelson dnelson@allantgroup.com --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pthreadscheck.diff" Index: Mk/bsd.port.mk =================================================================== RCS file: /home/ncvs/ports/Mk/bsd.port.mk,v retrieving revision 1.490 diff -u -r1.490 bsd.port.mk --- Mk/bsd.port.mk 31 May 2004 18:07:57 -0000 1.490 +++ Mk/bsd.port.mk 8 Jun 2004 14:59:04 -0000 @@ -3334,10 +3334,11 @@ # 1. setugid files # 2. accept()/recvfrom() which indicates network listening capability # 3. insecure functions (gets/mktemp/tempnam/[XXX]) -# 4. startup scripts, in conjunction with 2. -# 5. world-writable files/dirs +# 4. shared libs linked directly to pthreads libs +# 5. startup scripts, in conjunction with 2. +# 6. world-writable files/dirs # - -@${RM} -f ${WRKDIR}/.PLIST.setuid ${WRKDIR}/.PLIST.writable ${WRKDIR}/.PLIST.objdump; \ + -@${RM} -f ${WRKDIR}/.PLIST.setuid ${WRKDIR}/.PLIST.writable ${WRKDIR}/.PLIST.objdump ${WRKDIR}/.PLIST.ldd; \ ${AWK} -v prefix='${PREFIX}' ' \ match($$0, /^@cwd /) { prefix = substr($$0, RSTART + RLENGTH); next; } \ /^@/ { next; } \ @@ -3351,9 +3352,12 @@ ${TR} '\n' '\0' < ${WRKDIR}/.PLIST.flattened \ | ${XARGS} -0 -J % ${FIND} % -prune ! -type l -type f -print0 2> /dev/null \ | ${XARGS} -0 -n 1 /usr/bin/objdump -R 2> /dev/null > ${WRKDIR}/.PLIST.objdump; \ + ${GREP} '\.so' < ${WRKDIR}/.PLIST.flattened | ${TR} '\n' '\0' \ + | ${XARGS} -0 -J % ${FIND} % -prune ! -type l -type f -print0 2> /dev/null \ + | ${XARGS} -0 -n 1 /usr/bin/ldd -a 2> /dev/null > ${WRKDIR}/.PLIST.ldd; \ if \ ! ${AWK} -v audit="$${PORTS_AUDIT}" -f ${PORTSDIR}/Tools/scripts/security-check.awk \ - ${WRKDIR}/.PLIST.flattened ${WRKDIR}/.PLIST.objdump ${WRKDIR}/.PLIST.setuid ${WRKDIR}/.PLIST.writable; \ + ${WRKDIR}/.PLIST.flattened ${WRKDIR}/.PLIST.objdump ${WRKDIR}/.PLIST.ldd ${WRKDIR}/.PLIST.setuid ${WRKDIR}/.PLIST.writable; \ then \ www_site=$$(cd ${.CURDIR} && ${MAKE} ${__softMAKEFLAGS} www-site); \ if [ ! -z "$${www_site}" ]; then \ Index: Tools/scripts/security-check.awk =================================================================== RCS file: /home/ncvs/ports/Tools/scripts/security-check.awk,v retrieving revision 1.1 diff -u -r1.1 security-check.awk --- Tools/scripts/security-check.awk 19 Jan 2004 22:19:00 -0000 1.1 +++ Tools/scripts/security-check.awk 8 Jun 2004 14:38:09 -0000 @@ -9,6 +9,7 @@ split("", setuid_binaries); split("", writable_files); split("", startup_scripts); + split("", pthreads_libs); header_printed = 0; } FILENAME ~ /\.flattened$/ { @@ -18,7 +19,6 @@ FILENAME ~ /\.objdump$/ { if (match($0, /: +file format [^ ]+$/)) { file = substr($0, 1, RSTART - 1); - stupid_functions = ""; next; } if (file == "") @@ -29,6 +29,16 @@ if ($3 ~ /^(accept|recvfrom)$/) network_binaries[file] = 1; } +FILENAME ~ /\.ldd$/ { + if (match($0, /:$/)) { + file = substr($0, 1, RSTART - 1); + next; + } + if (file == "") + next; + if ($1 ~ /^(libc_r|libpthread|libthr).so/) + pthreads_libs[file] = $3; +} FILENAME ~ /\.setuid$/ { setuid_binaries[$0] = 1; } FILENAME ~ /\.writable$/ { writable_files[$0] = 1; } function print_header() { @@ -79,6 +89,20 @@ if (note_printed) print ""; } + + note_printed = 0; + for (file in pthreads_libs) { + if (!note_printed) { + print_header(); + print " This port has installed the following shared libraries which are"; + print " incorrectly linked to a pthreads shared library."; + note_printed = 1; + } + printf "%s (linked to %s)\n", file, pthreads_libs[file]; + } + if (note_printed) + print ""; + note_printed = 0; for (file in writable_files) { if (!note_printed) { --zYM0uCDKw75PZbzx-- From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 8 17:57:24 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F13716A4CE; Tue, 8 Jun 2004 17:57:24 +0000 (GMT) Received: from creme-brulee.marcuscom.com (rrcs-midsouth-24-172-16-118.biz.rr.com [24.172.16.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8CB443D2D; Tue, 8 Jun 2004 17:57:23 +0000 (GMT) (envelope-from marcus@marcuscom.com) Received: from [192.168.1.4] (shumai.marcuscom.com [192.168.1.4]) i58HuMZm003561; Tue, 8 Jun 2004 13:56:22 -0400 (EDT) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: Dan Nelson In-Reply-To: <20040608154510.GB89198@dan.emsphone.com> References: <1086663455.1258.79.camel@server.mcneil.com> <20040608044844.GA89198@dan.emsphone.com> <20040608072706.GA82243@xor.obsecurity.org> <20040608154510.GB89198@dan.emsphone.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-FnZVoL0BYwSU0eYirIzC" Organization: MarcusCom, Inc. Message-Id: <1086717435.68846.9.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 08 Jun 2004 13:57:16 -0400 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on creme-brulee.marcuscom.com cc: freebsd-amd64@freebsd.org cc: freebsd-gnome@freebsd.org cc: freebsd-threads@freebsd.org cc: freebsd-current@freebsd.org cc: Kris Kennaway cc: Sean McNeil Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 17:57:24 -0000 --=-FnZVoL0BYwSU0eYirIzC Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2004-06-08 at 11:45, Dan Nelson wrote: > In the last episode (Jun 08), Kris Kennaway said: > > On Mon, Jun 07, 2004 at 11:48:45PM -0500, Dan Nelson wrote: > > > In the last episode (Jun 08), Daniel Eischen said: > > > > No, I don't want to litter all our thread libraries with strong > > > > references. As I've said before, build your shared libraries > > > > correctly so they don't bring in the threads library. > > >=20 > > > A good addition to bsd.port.mk, right next to the "possible network > > > server" etc checks, might be to run ldd on all installed shared > > > libraries and print a warning if any threads libraries show up. Ther= e > > > are a huge number of ports that install shlibs linked to libpthreads. > >=20 > > Some of these are probably correct, in that the library started using > > libpthreads internally and there are a large number of clients that > > would otherwise need to be changed to link to that library. >=20 > I don't think you can have it both ways, though. The rule is either > "pthreads-using shared libraries should pull in a pthreads lib > themselves" or "programs wanting to link to pthreads-using shared > libraries should link with a pthreads lib". >=20 > Attached are patches to add this check to the security-check target.=20 > Ideally they would be checked separately or flagged as something other > than security problems, but that would require copying > security-check.awk and a larger diff.. If we switched PTHREAD_LIBS to -pthread, we wouldn't need this. Shared objects would not have a link to libpthread, and shared objects that really referenced pthread symbols would still require executables to be linked to PTHREAD_LIBS (i.e. how it works on 4.X). Joe --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-FnZVoL0BYwSU0eYirIzC Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAxf37b2iPiv4Uz4cRAmjEAJ9eZKBGVjPP0j7K+IPemwL49iNo7gCfVmGb 7LWrJiKxUkm7wAmN+o44+A0= =fnCz -----END PGP SIGNATURE----- --=-FnZVoL0BYwSU0eYirIzC-- From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 8 19:58:52 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B42E16A4CE; Tue, 8 Jun 2004 19:58:52 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2631143D39; Tue, 8 Jun 2004 19:58:52 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.10/8.12.10) id i58JwpD0027730; Tue, 8 Jun 2004 14:58:51 -0500 (CDT) (envelope-from dan) Date: Tue, 8 Jun 2004 14:58:50 -0500 From: Dan Nelson To: Joe Marcus Clarke Message-ID: <20040608195850.GB46338@dan.emsphone.com> References: <1086663455.1258.79.camel@server.mcneil.com> <20040608044844.GA89198@dan.emsphone.com> <20040608072706.GA82243@xor.obsecurity.org> <20040608154510.GB89198@dan.emsphone.com> <1086717435.68846.9.camel@shumai.marcuscom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1086717435.68846.9.camel@shumai.marcuscom.com> X-OS: FreeBSD 5.2-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: freebsd-amd64@freebsd.org cc: freebsd-gnome@freebsd.org cc: freebsd-threads@freebsd.org cc: freebsd-current@freebsd.org cc: Kris Kennaway cc: Sean McNeil Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 19:58:52 -0000 In the last episode (Jun 08), Joe Marcus Clarke said: > If we switched PTHREAD_LIBS to -pthread, we wouldn't need this. Shared > objects would not have a link to libpthread, and shared objects that > really referenced pthread symbols would still require executables to be > linked to PTHREAD_LIBS (i.e. how it works on 4.X). It'd still be a good sanity check for people porting libraries, I think. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 8 22:20:54 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F03C716A4CE for ; Tue, 8 Jun 2004 22:20:54 +0000 (GMT) Received: from lakermmtao09.cox.net (lakermmtao09.cox.net [68.230.240.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53DD043D41 for ; Tue, 8 Jun 2004 22:20:54 +0000 (GMT) (envelope-from conrads@ip68-11-70-23.no.no.cox.net) Received: from ip68-11-70-23.no.no.cox.net ([68.11.70.23]) by lakermmtao09.cox.netESMTP <20040608222052.VWZT24996.lakermmtao09.cox.net@ip68-11-70-23.no.no.cox.net> for ; Tue, 8 Jun 2004 18:20:52 -0400 Received: from ip68-11-70-23.no.no.cox.net (localhost [127.0.0.1]) i58MKgK4001270 for ; Tue, 8 Jun 2004 17:20:42 -0500 (CDT) (envelope-from conrads@ip68-11-70-23.no.no.cox.net) Received: (from conrads@localhost)i58MKgRS001269 for freebsd-amd64@freebsd.org; Tue, 8 Jun 2004 17:20:42 -0500 (CDT) (envelope-from conrads) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Tue, 08 Jun 2004 17:20:42 -0500 (CDT) Sender: conrads@ip68-11-70-23.no.no.cox.net From: "Conrad J. Sabatier" To: freebsd-amd64@freebsd.org Subject: Bootstrapping a 64-bit environment starting with a 5.2.1-RELEASE CD set X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 22:20:55 -0000 I hope this isn't considered off-topic for this list (as in, more appropriate maybe for the questions list). I just bought a new AMD64 system yesterday, and I'm wondering how to go about building a complete 64-bit environment, starting from a 5.2.1-RELEASE install. The initial install of gcc won't support the -m64 option, although it does seem to support all the other CPU-specific options. What /etc/make.conf options, kernel options are recommended and/or discouraged, and how many builds will be needed in order to bring up the final environment? Are there any potential "gotchas" to beware of? Are there any good online sources for this information? I do very much appreciate any advice. Thanks! -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 8 22:27:38 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B82216A4CE for ; Tue, 8 Jun 2004 22:27:38 +0000 (GMT) Received: from lakermmtao04.cox.net (lakermmtao04.cox.net [68.230.240.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id C49AC43D49 for ; Tue, 8 Jun 2004 22:27:37 +0000 (GMT) (envelope-from conrads@ip68-11-70-23.no.no.cox.net) Received: from ip68-11-70-23.no.no.cox.net ([68.11.70.23]) by lakermmtao04.cox.netESMTP <20040608222737.VPGL12116.lakermmtao04.cox.net@ip68-11-70-23.no.no.cox.net>; Tue, 8 Jun 2004 18:27:37 -0400 Received: from ip68-11-70-23.no.no.cox.net (localhost [127.0.0.1]) i58MRZK4001322; Tue, 8 Jun 2004 17:27:35 -0500 (CDT) (envelope-from conrads@ip68-11-70-23.no.no.cox.net) Received: (from conrads@localhost)i58MRZBd001321; Tue, 8 Jun 2004 17:27:35 -0500 (CDT) (envelope-from conrads) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 08 Jun 2004 17:27:30 -0500 (CDT) Sender: conrads@ip68-11-70-23.no.no.cox.net From: "Conrad J. Sabatier" To: "Conrad J. Sabatier" cc: freebsd-amd64@freebsd.org Subject: Re: Bootstrapping a 64-bit environment starting with a 5.2.1-RELEASE CD set X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 22:27:38 -0000 Please disregard. I just checked and found the AMD64 ISOs. Duh! :-) On 08-Jun-2004 Conrad J. Sabatier wrote: > I hope this isn't considered off-topic for this list (as in, more appropriate > maybe for the questions list). > > I just bought a new AMD64 system yesterday, and I'm wondering how to go about > building a complete 64-bit environment, starting from a 5.2.1-RELEASE > install. > The initial install of gcc won't support the -m64 option, although it does > seem > to support all the other CPU-specific options. > > What /etc/make.conf options, kernel options are recommended and/or > discouraged, > and how many builds will be needed in order to bring up the final > environment? > > Are there any potential "gotchas" to beware of? Are there any good online > sources for this information? > > I do very much appreciate any advice. Thanks! > > -- > Conrad J. Sabatier -- "In Unix veritas" > ---------------------------------- E-Mail: Conrad J. Sabatier Date: 08-Jun-2004 Time: 17:26:52 This message was sent by XFMail ---------------------------------- From owner-freebsd-amd64@FreeBSD.ORG Wed Jun 9 02:43:33 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D00CC16A4CE; Wed, 9 Jun 2004 02:43:33 +0000 (GMT) Received: from corbulon.video-collage.com (corbulon.video-collage.com [64.35.99.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4032743D5A; Wed, 9 Jun 2004 02:43:33 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from 250-217.customer.cloud9.net (195-11.customer.cloud9.net [168.100.195.11])i592hOqx044587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Jun 2004 22:43:25 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from localhost (mteterin@localhost [127.0.0.1]) i58KHUMr055331; Tue, 8 Jun 2004 16:17:30 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) From: Mikhail Teterin Organization: Virtual Estates, Inc. To: freebsd-amd64@FreeBSD.org, freebsd-current@FreeBSD.org Date: Tue, 8 Jun 2004 16:17:29 -0400 User-Agent: KMail/1.6.1 MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_Z7hxAxJ0mHx1yJi" Message-Id: <200406081617.29485@misha-mx.virtual-estates.net> X-Virus-Scanned: clamd / ClamAV version devel-20040604, clamav-milter version 0.71c on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.39 cc: SCHA Subject: continuing troubles with AMD64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 02:43:34 -0000 --Boundary-00=_Z7hxAxJ0mHx1yJi Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline The good part: the Mar 1st -current kernel works fine. The bad: 1) Any newer kernels don't see the system drive, presumably, abecause ttempts to allocate IRQs for the all of the aata-controllers fail. 2) Yesterday's kernel panics with: madt_probe_cpus_handler: CPU ID 129 too high Indeed, 129 is greater than NLAPICS, which is 32, but the Mar 1st kernel works. We can work around the second problem by disabling the APIC in the BIOS, or by disabling the ACPI altogether on the loader's prompt. We did not yet find the workaround for 1), however. All of the ata-controllers and some other hardware (like firewire) report "unable to allocate IRQ" with any of the more recent kernels. I'm attaching the dmesg.boot, as obtained with the Mar 1st kernel. Please, advise. Thanks! -mi --Boundary-00=_Z7hxAxJ0mHx1yJi Content-Type: text/plain; charset="us-ascii"; name="pandora-dmesg.boot" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="pandora-dmesg.boot" ioapic0: intpin 7 -> irq 7 (edge, activehi) ioapic0: intpin 8 -> irq 8 (edge, activehi) ioapic0: intpin 9 -> irq 9 (edge, activehi) ioapic0: intpin 10 -> irq 10 (edge, activehi) ioapic0: intpin 11 -> irq 11 (edge, activehi) ioapic0: intpin 12 -> irq 12 (edge, activehi) ioapic0: intpin 13 -> irq 13 (edge, activehi) ioapic0: intpin 14 -> irq 14 (edge, activehi) ioapic0: intpin 15 -> irq 15 (edge, activehi) ioapic0: intpin 16 -> irq 16 (level, activelo) ioapic0: intpin 17 -> irq 17 (level, activelo) ioapic0: intpin 18 -> irq 18 (level, activelo) ioapic0: intpin 19 -> irq 19 (level, activelo) ioapic0: intpin 20 -> irq 20 (level, activelo) ioapic0: intpin 21 -> irq 21 (level, activelo) ioapic0: intpin 22 -> irq 22 (level, activelo) ioapic0: intpin 23 -> irq 23 (level, activelo) MADT: Found IO APIC ID 2, Interrupt 24 at 0xff4fe000 ioapic1: intpin 0 -> irq 24 (level, activelo) ioapic1: intpin 1 -> irq 25 (level, activelo) ioapic1: intpin 2 -> irq 26 (level, activelo) ioapic1: intpin 3 -> irq 27 (level, activelo) MADT: Found IO APIC ID 3, Interrupt 28 at 0xff4ff000 ioapic2: intpin 0 -> irq 28 (level, activelo) ioapic2: intpin 1 -> irq 29 (level, activelo) ioapic2: intpin 2 -> irq 30 (level, activelo) ioapic2: intpin 3 -> irq 31 (level, activelo) MADT: intr override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 polarity: active-hi ioapic0: intpin 2 trigger: edge ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-27 on motherboard ioapic2 irqs 28-31 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00040010 LDR: 0x01000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff random: mem: null: acpi0: on motherboard pci_open(1): mode 1 addr port (0x0cf8) is 0x800358b0 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 1 2 3 4 5 6 [class=060400] [hdr=01] is there (id=74601022) AcpiOsDerivePciId: bus 0 dev 7 func 0 AcpiOsDerivePciId: bus 0 dev 7 func 1 AcpiOsDerivePciId: bus 0 dev 7 func 3 acpi0: Power Button (fixed) AcpiOsDerivePciId: bus 0 dev 10 func 0 AcpiOsDerivePciId: bus 0 dev 11 func 0 ACPI timer looks GOOD min = 3, max = 4, width = 1 ACPI timer looks GOOD min = 3, max = 4, width = 1 ACPI timer looks GOOD min = 3, max = 4, width = 1 ACPI timer looks GOOD min = 3, max = 4, width = 1 ACPI timer looks GOOD min = 3, max = 4, width = 1 ACPI timer looks GOOD min = 3, max = 4, width = 1 ACPI timer looks GOOD min = 3, max = 4, width = 1 ACPI timer looks GOOD min = 3, max = 4, width = 1 ACPI timer looks GOOD min = 3, max = 4, width = 1 ACPI timer looks GOOD min = 3, max = 4, width = 1 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x5008-0x500b on acpi0 mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) acpi_cpu0: port 0x530-0x537 on acpi0 mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) acpi_cpu1: port 0x530-0x537 on acpi0 device_probe_and_attach: acpi_cpu1 attach returned 6 pcib0: port 0xcf8-0xcff on acpi0 ---- initial configuration ------------------------ ---- before setting priority for links ------------ ---- before fixup boot-disabled links ------------- ---- after fixup boot-disabled links -------------- ---- arbitrated configuration --------------------- pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x1022, dev=0x7460, revid=0x07 bus=0, slot=6, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0117, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x07 (1750 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x7468, revid=0x05 bus=0, slot=7, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000ffa0, size 4, enabled found-> vendor=0x1022, dev=0x7469, revid=0x03 bus=0, slot=7, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 4, range 32, base 0000a480, size 5, enabled pcib0: matched entry for 0.7.INTD (source ) pcib0: device is hardwired to IRQ 19 found-> vendor=0x1022, dev=0x746a, revid=0x02 bus=0, slot=7, func=2 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=19 found-> vendor=0x1022, dev=0x746b, revid=0x05 bus=0, slot=7, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 4, range 32, base 0000a800, size 8, enabled map[14]: type 4, range 32, base 0000ac00, size 6, enabled pcib0: matched entry for 0.7.INTB (source ) pcib0: device is hardwired to IRQ 17 found-> vendor=0x1022, dev=0x746d, revid=0x03 bus=0, slot=7, func=5 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=17 found-> vendor=0x1022, dev=0x7450, revid=0x12 bus=0, slot=10, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0116, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x05 (1250 ns), maxlat=0x00 (0 ns) map[10]: type 1, range 64, base ff4fe000, size 12, enabled found-> vendor=0x1022, dev=0x7451, revid=0x01 bus=0, slot=10, func=1 class=08-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 1, range 64, base 00000000, size 12, enabled found-> vendor=0x1022, dev=0x7450, revid=0x12 bus=0, slot=11, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0116, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x05 (1250 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[10]: type 1, range 64, base ff4ff000, size 12, enabled found-> vendor=0x1022, dev=0x7451, revid=0x01 bus=0, slot=11, func=1 class=08-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1100, revid=0x00 bus=0, slot=24, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1101, revid=0x00 bus=0, slot=24, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1102, revid=0x00 bus=0, slot=24, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1103, revid=0x00 bus=0, slot=24, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pcib1: at device 6.0 on pci0 pcib1: secondary bus 3 pcib1: subordinate bus 3 pcib1: I/O decode 0x8000-0x8fff pcib1: memory decode 0xff200000-0xff3fffff pcib1: prefetched decode 0xe6800000-0xe68fffff ---- initial configuration ------------------------ ---- before setting priority for links ------------ ---- before fixup boot-disabled links ------------- ---- after fixup boot-disabled links -------------- ---- arbitrated configuration --------------------- pci3: on pcib1 pci3: physical bus=3 map[10]: type 1, range 32, base ff3fc000, size 12, enabled pcib1: matched entry for 3.0.INTD (source ) pcib1: device is hardwired to IRQ 19 found-> vendor=0x1022, dev=0x7464, revid=0x0b bus=3, slot=0, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0117, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x50 (20000 ns) intpin=d, irq=19 map[10]: type 1, range 32, base ff3fd000, size 12, enabled pcib1: matched entry for 3.0.INTD (source ) pcib1: device is hardwired to IRQ 19 found-> vendor=0x1022, dev=0x7464, revid=0x0b bus=3, slot=0, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x50 (20000 ns) intpin=d, irq=19 map[10]: type 4, range 32, base 00008000, size 8, enabled map[14]: type 1, range 32, base ff3fe000, size 12, enabled pcib1: matched entry for 3.10.INTA (source ) pcib1: device is hardwired to IRQ 16 found-> vendor=0x9004, dev=0x8178, revid=0x00 bus=3, slot=10, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0280, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x08 (2000 ns) intpin=a, irq=16 map[10]: type 4, range 32, base 00008c00, size 3, enabled map[14]: type 4, range 32, base 00008880, size 2, enabled map[18]: type 4, range 32, base 00008800, size 3, enabled map[1c]: type 4, range 32, base 00008480, size 2, enabled map[20]: type 4, range 32, base 00008400, size 4, enabled map[24]: type 1, range 32, base ff3ffc00, size 10, enabled pcib1: matched entry for 3.11.INTA (source ) pcib1: device is hardwired to IRQ 17 found-> vendor=0x1095, dev=0x3114, revid=0x02 bus=3, slot=11, func=0 class=01-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=17 powerspec 2 supports D0 D1 D2 D3 current D0 ohci0: mem 0xff3fc000-0xff3fcfff irq 19 at device 0.0 on pci3 pcib1: device ohci0 requested decoded memory range 0xff3fc000-0xff3fcfff usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xff3fd000-0xff3fdfff irq 19 at device 0.1 on pci3 pcib1: device ohci1 requested decoded memory range 0xff3fd000-0xff3fdfff usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered ahc0: port 0x8000-0x80ff mem 0xff3fe000-0xff3fefff irq 16 at device 10.0 on pci3 ahc0: Defaulting to MEMIO off pcib1: device ahc0 requested decoded I/O range 0x8000-0x80ff ahc0: Enabling 39Bit Addressing ahc0: Reading SEEPROM...done. ahc0: internal 50 cable not present, internal 68 cable is present ahc0: external cable not present ahc0: BIOS eeprom is present ahc0: High byte termination Enabled ahc0: Low byte termination Enabled ahc0: Downloading Sequencer Program... 457 instructions downloaded ahc0: Features 0x10005, Bugs 0x25, Flags 0x21401540 aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs atapci0: port 0x8400-0x840f,0x8480-0x8483,0x8800-0x8807,0x8880-0x8883,0x8c00-0x8c07 mem 0xff3ffc00-0xff3fffff irq 17 at device 11.0 on pci3 pcib1: device atapci0 requested decoded I/O range 0x8400-0x840f atapci0: [MPSAFE] pcib1: device atapci0 requested decoded memory range 0xff3ffc00-0xff3fffff ata2: reset tp1 mask=01 ostat0=50 ostat1=50 ata2-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 mask=01 stat0=50 stat1=00 devices=0x1 ata2: at 0xff3ffc00 on atapci0 ata2: [MPSAFE] ata3: reset tp1 mask=01 ostat0=7f ostat1=7f ata3-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata3-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata3-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata3-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata3-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata3-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata3-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata3-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata3-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata3-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata3-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata3-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata3-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata3-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata3-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata3-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata3-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata3-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata3-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata3-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata3-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata3-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata3: reset tp2 mask=00 stat0=ff stat1=00 devices=0x0 ata3: at 0xff3ffc00 on atapci0 ata3: [MPSAFE] ata4: at 0xff3ffc00 on atapci0 ata4: [MPSAFE] ata5: at 0xff3ffc00 on atapci0 ata5: [MPSAFE] isab0: at device 7.0 on pci0 isa0: on isab0 atapci1: port 0xffa0-0xffaf at device 7.1 on pci0 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0-master: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata0-slave: stat=0x00 err=0x00 lsb=0x14 msb=0xeb ata0: reset tp2 mask=03 stat0=00 stat1=00 devices=0x4 ata0: at 0x1f0 irq 14 on atapci1 ata0: [MPSAFE] ata1: reset tp1 mask=03 ostat0=50 ostat1=7f ata1-master: stat=0x10 err=0x01 lsb=0x14 msb=0xeb ata1-slave: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata1-slave: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata1-slave: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata1-slave: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata1-slave: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata1-slave: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata1-slave: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata1-slave: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata1-slave: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata1-slave: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata1-slave: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata1-slave: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata1-slave: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata1-slave: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata1-slave: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata1-slave: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata1-slave: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata1-slave: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata1-slave: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata1-slave: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata1-slave: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata1-slave: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata1-slave: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata1: reset tp2 mask=01 stat0=10 stat1=ff devices=0x4 ata1: at 0x170 irq 15 on atapci1 ata1: [MPSAFE] pci0: at device 7.2 (no driver attached) pci0: at device 7.3 (no driver attached) pcm0: port 0xac00-0xac3f,0xa800-0xa8ff irq 17 at device 7.5 on pci0 pcm0: pcm0: Codec features headphone, 20 bit DAC, 5 bit master volume, no 3D Stereo Enhancement pcm0: Primary codec extended features variable rate PCM, reserved 1, AMAP, reserved 4 pcm0: sndbuf_setmap a8b000, 4000; 0xffffffffb60c7000 -> a8b000 pcm0: sndbuf_setmap a91000, 4000; 0xffffffffb60cb000 -> a91000 pcib2: at device 10.0 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0x0-0x0 pcib2: memory decode 0xff100000-0xff1fffff pcib2: prefetched decode 0xe6700000-0xe67fffff ---- initial configuration ------------------------ ---- before setting priority for links ------------ ---- before fixup boot-disabled links ------------- ---- after fixup boot-disabled links -------------- ---- arbitrated configuration --------------------- pci2: on pcib2 pci2: physical bus=2 map[10]: type 3, range 32, base e67f0000, size 16, enabled pcib2: matched entry for 2.7.INTA (source ) pcib2: device is hardwired to IRQ 26 found-> vendor=0x1000, dev=0x1960, revid=0x01 bus=2, slot=7, func=0 class=01-04-00, hdrtype=0x00, mfdev=0 cmdreg=0x0116, statreg=0x04b0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=26 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 64, base ff1f0000, size 16, enabled pcib2: matched entry for 2.9.INTA (source ) pcib2: device is hardwired to IRQ 24 found-> vendor=0x14e4, dev=0x16a7, revid=0x02 bus=2, slot=9, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0116, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns) intpin=a, irq=24 powerspec 2 supports D0 D3 current D0 MSI supports 8 messages, 64 bit amr0: mem 0xe67f0000-0xe67fffff irq 26 at device 7.0 on pci2 pcib2: device amr0 requested decoded memory range 0xe67f0000-0xe67fffff amr0: Firmware 712T, BIOS G116, 64MB RAM bge0: mem 0xff1f0000-0xff1fffff irq 24 at device 9.0 on pci2 pcib2: device bge0 requested decoded memory range 0xff1f0000-0xff1fffff bge0: Ethernet address: 00:e0:81:28:21:04 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: bpf attached pci0: at device 10.1 (no driver attached) pcib3: mem 0-0xfff at device 11.0 on pci0 pcib3: secondary bus 1 pcib3: subordinate bus 1 pcib3: I/O decode 0x0-0x0 pcib3: memory decode 0xff000000-0xff0fffff pcib3: prefetched decode 0xe6600000-0xe66fffff ---- initial configuration ------------------------ ---- before setting priority for links ------------ ---- before fixup boot-disabled links ------------- ---- after fixup boot-disabled links -------------- ---- arbitrated configuration --------------------- pci1: on pcib3 pci1: physical bus=1 pci0: at device 11.1 (no driver attached) pcib4: on acpi0 pcib4: could not get PCI interrupt routing table for \\_SB_.PCIB - AE_NOT_FOUND pci4: on pcib4 pci4: physical bus=4 map[10]: type 3, range 32, base f0000000, size 27, enabled found-> vendor=0x1022, dev=0x7454, revid=0x13 bus=4, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x7455, revid=0x13 bus=4, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) pcib5: at device 1.0 on pci4 pcib5: secondary bus 5 pcib5: subordinate bus 5 pcib5: I/O decode 0xb000-0xbfff pcib5: memory decode 0xff500000-0xff5fffff pcib5: prefetched decode 0xe6a00000-0xeeafffff ---- initial configuration ------------------------ ---- before setting priority for links ------------ ---- before fixup boot-disabled links ------------- ---- after fixup boot-disabled links -------------- ---- arbitrated configuration --------------------- pci5: on pcib5 pci5: physical bus=5 map[10]: type 3, range 32, base e8000000, size 26, enabled map[14]: type 4, range 32, base 0000b800, size 8, enabled map[18]: type 1, range 32, base ff5fc000, size 14, enabled found-> vendor=0x1002, dev=0x5446, revid=0x00 bus=5, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0087, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D3 current D0 pci5: at device 0.0 (no driver attached) acpi_button0: on acpi0 mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d0000 psm0: unable to allocate IRQ unknown: not probed (disabled) sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0 0 0 0 sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: using extended I/O port range ppc0: SPP ppc0 port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port unknown: not probed (disabled) unknown: not probed (disabled) mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) mss_detect, busy still set (0xff) acpi_cpu1: port 0x530-0x537 on acpi0 device_probe_and_attach: acpi_cpu1 attach returned 6 mss_detect, busy still set (0xff) mss_detect, busy still set (0xff) mss_detect, busy still set (0xff) mss_detect, busy still set (0xff) mss_detect, busy still set (0xff) mss_detect, busy still set (0xff) mss_detect, busy still set (0xff) mss_detect, busy still set (0xff) mss_detect, busy still set (0xff) mss_detect, busy still set (0xff) mss_detect, busy still set (0xff) mss_detect, busy still set (0xff) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) mss_detect, busy still set (0xff) mss_detect, busy still set (0xff) mss_detect, busy still set (0xff) mss_detect, busy still set (0xff) mss_detect, busy still set (0xff) mss_detect, busy still set (0xff) mss_detect, busy still set (0xff) atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: