From owner-freebsd-arch@FreeBSD.ORG Wed Apr 13 18:08:25 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3149F16A4CE; Wed, 13 Apr 2005 18:08:25 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id C053243D39; Wed, 13 Apr 2005 18:08:24 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j3DI8Otx065966; Wed, 13 Apr 2005 13:08:24 -0500 (CDT) (envelope-from dan) Date: Wed, 13 Apr 2005 13:08:24 -0500 From: Dan Nelson To: Scott Long Message-ID: <20050413180824.GE4842@dan.emsphone.com> References: <425D2041.7020501@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <425D2041.7020501@samsco.org> X-OS: FreeBSD 5.4-PRERELEASE X-message-flag: Outlook Error User-Agent: Mutt/1.5.8i cc: arch@freebsd.org cc: re@freebsd.org cc: David Xu Subject: Re: HEADS-UP: Planning on deprecating libc_r for 6.0 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 18:08:25 -0000 In the last episode (Apr 13), Scott Long said: > Now that we've had working KSE for 2 years, I'm planning to declare > that libc_r will be deprecated in 6.0 and removed by or before 7.0. > That means that libc_r will still be built and installed and usable > for 6.0 and likely for most of the 6.x lifetime, but its visibility > will decrease in favor of libpthread and possibly libthr. Given that > 7.0 is at least 2 years away, that should give plenty of time for > migration and testing. I assume that libc_r will also live on in > compatibility library archives long after that for those with legacy > apps. On a somewhat related note (libpthread/libthr feature parity with libc_r), is there any way to get truss to be kse/thr aware? Currently you can't trace kernel-threaded apps because the thread-switching syscalls get in the way. Compare the output of: truss host www.yahoo.com LD_LIBMAP=libpthread.so.1=libthr.so.1 truss host www.yahoo.com LD_LIBMAP=libpthread.so.1=libc_r.so.5 truss host www.yahoo.com The libc_r one is the only one with useable output. ports/sysutils/pstack (prints the stacks of a running process) is another handy tool that's libc_r only. Is libthread_db something that can help here and hide the differences between the libs? -- Dan Nelson dnelson@allantgroup.com