From owner-freebsd-threads@FreeBSD.ORG Wed Sep 21 17:30:12 2005 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1378F16A41F for ; Wed, 21 Sep 2005 17:30:12 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D316F43D45 for ; Wed, 21 Sep 2005 17:30:11 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j8LHUBC5049080 for ; Wed, 21 Sep 2005 17:30:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j8LHUBju049079; Wed, 21 Sep 2005 17:30:11 GMT (envelope-from gnats) Date: Wed, 21 Sep 2005 17:30:11 GMT Message-Id: <200509211730.j8LHUBju049079@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Daniel Eischen Cc: Subject: Re: kern/86029: undefined reference to `_thread_dump_info' X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2005 17:30:12 -0000 The following reply was made to PR kern/86029; it has been noted by GNATS. From: Daniel Eischen To: Christopher Sean Morrison Cc: David Xu , Subject: Re: kern/86029: undefined reference to `_thread_dump_info' Date: Wed, 21 Sep 2005 13:28:09 -0400 (EDT) On Wed, 21 Sep 2005, Christopher Sean Morrison wrote: > David, > > This function was being used by a chunk of low level threading code in > the BRL-CAD that has been in use since '98 for dumping out extra state > information when thread creation fails. We don't "want" to use it, it > just has been used for so long in the code for the very same reason > that it's used by the posix threading library -- it's very useful for > debugging and investigating failures. That's what SIGINFO is for. Again, that's undocumented and allowed to change, but it's better than calling a library internal function. > For what it's worth, this routine was in fact documented in the OpenBSD > notes for c_r as being useful for exactly that purpose. Again, this is > nothing new, either -- doesn't make it right, but what are the > alternatives? The only difference seems to be the change on this AMD64 > box to not utilize -lc_r when -pthread is provided on the compile line. OpenBSD took our libc_r. If _thread_dump_info() was supposed to be callable from the outside, it would have been named pthread_dump_info_np(). > I've got no issue removing the call from our code, but it seems > indicative of a larger change to what -pthread means. If -pthread no > longer implies linking against c_r for whatever reason, that would be > the fundamental difference here that we'll need to accommodate in our > build. In that regard, what non-private routine will provide similar > details when thread creation fails? -pthread means do whatever is necessary to link in the threads library. In 5.x and subsequent, the threads library is libpthread, not libc_r. pthread_create() should return a useful errno if it can't create a thread. -- DE