From nobody@FreeBSD.org  Mon Sep 12 21:12:15 2005
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id E338816A41F
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 12 Sep 2005 21:12:15 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id B278B43D48
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 12 Sep 2005 21:12:15 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id j8CLCFdd083018
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 12 Sep 2005 21:12:15 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id j8CLCFZT083017;
	Mon, 12 Sep 2005 21:12:15 GMT
	(envelope-from nobody)
Message-Id: <200509122112.j8CLCFZT083017@www.freebsd.org>
Date: Mon, 12 Sep 2005 21:12:15 GMT
From: Christopher Sean Morrison <brlcad@mac.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: undefined reference to `_thread_dump_info'
X-Send-Pr-Version: www-2.3

>Number:         86029
>Category:       kern
>Synopsis:       undefined reference to `_thread_dump_info'
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-threads
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Sep 12 21:20:13 GMT 2005
>Closed-Date:    Thu Oct 06 22:16:34 GMT 2005
>Last-Modified:  Thu Oct 06 22:16:34 GMT 2005
>Originator:     Christopher Sean Morrison
>Release:        5.4-RELEASE-p6
>Organization:
BRL-CAD Lead Developer
>Environment:
FreeBSD *.*.*.* 5.4-RELEASE-p6 FreeBSD 5.4-RELEASE-p6 #0: Wed Sep  7 17:41:09 EST 2005     *@*.*.*.*:/usr/src/sys/amd64/compile/SMP  amd64
>Description:
Compiling code that uses the _thread_dump_info() call that should be in c_r fails with an unresolved symbol reference.  The symbol does show up in an nm of libc_r but c_r is apparently not used when -pthread is passed to the compiler/linker.  This same compilation on an identically configured ia32 freebsd install does not exhibit this same problem.

The code in question is being compiled through libtool which also presumes (as has been documented in the past, yes?) that -pthread takes care of providing -lc_r.  The script specifically tests for -lc_r ldflags and removes them when using -pthread.
>How-To-Repeat:
Compile and link against code that uses _thread_dump_info() using -pthread without manually adding -lc_r.
>Fix:
Manually compiling outside of libtool and adding -lc_r seems to fix the problem.  Similarly, tricking the libtool script by passing a cflag instead of an ldflag works:
make CFLAGS=-Wl,-lc_r
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-threads 
Responsible-Changed-By: kris 
Responsible-Changed-When: Wed Sep 21 07:06:59 GMT 2005 
Responsible-Changed-Why:  
Assign to threads mailing list 

http://www.freebsd.org/cgi/query-pr.cgi?pr=86029 

From: David Xu <davidxu@freebsd.org>
To: bug-followup@freebsd.org, brlcad@mac.com
Cc:  
Subject: Re: kern/86029: undefined reference to `_thread_dump_info'
Date: Wed, 21 Sep 2005 15:40:25 +0800

 _thread_dump_info() is an undocumented function and for internal
 use only in libpthread, why do you want to use it ?
 
 David Xu
 
 

From: "Daniel M. Eischen" <eischen@vigrid.com>
To: bug-followup@FreeBSD.org, brlcad@mac.com
Cc:  
Subject: Re: kern/86029: undefined reference to `_thread_dump_info'
Date: Wed, 21 Sep 2005 09:48:37 -0400

 Yes, this is an internal function (it begins with an underscore).
 It does not exist in libpthread.  This bug should be closed.

From: Christopher Sean Morrison <brlcad@mac.com>
To: David Xu <davidxu@freebsd.org>
Cc: "Daniel M. Eischen" <eischen@vigrid.com>, bug-followup@freebsd.org
Subject: Re: kern/86029: undefined reference to `_thread_dump_info'
Date: Wed, 21 Sep 2005 10:33:08 -0400

 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.
 
 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.
 
 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?
 
 Sean
 
 
 On Sep 21, 2005, at 3:40 AM, David Xu wrote:
 
 > _thread_dump_info() is an undocumented function and for internal
 > use only in libpthread, why do you want to use it ?
 >
 > David Xu
 

From: Christopher Sean Morrison <brlcad@mac.com>
To: "Daniel M. Eischen" <eischen@vigrid.com>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/86029: undefined reference to `_thread_dump_info'
Date: Wed, 21 Sep 2005 10:50:35 -0400

 The issue is not with libpthread  (i.e. -lpthread) but with the 
 -pthread option to gcc.  The symbol itself is provided via libc_r, not 
 libpthread.  As the bug report notes, everything works if I link 
 against -lc_r which was unexpected when already passing -pthread.
 
 I'm also not contesting whether we should or shouldn't be using 
 _thread_dump_info at all, it's just the symbol that exposed the issue.  
 The difference here seems to be that gcc's -pthread option on amd64's 
 behaves differently than other systems by not linking against c_r.  If 
 this was intentional, then I'd agree that it's not a bug.  If it 
 wasn't, the bug would perhaps be that it should be linking against 
 -lc_r.
 
 We're seeing several other threading problems on AMD64 and some of them 
 I believe are related to re-entrance issues and stack corruption.  
 Crashes deep inside C library calls are particularly interesting.  From 
 other bug report traffic from a month or few ago, it would seem at 
 least some of these issues may be fixed in a later release (we're 
 sitting on 5.4)..
 
 Cheers!
 Sean
 
 
 On Sep 21, 2005, at 9:48 AM, Daniel M. Eischen wrote:
 
 > Yes, this is an internal function (it begins with an underscore).
 > It does not exist in libpthread.  This bug should be closed.
 

From: Daniel Eischen <deischen@freebsd.org>
To: Christopher Sean Morrison <brlcad@mac.com>
Cc: David Xu <davidxu@freebsd.org>, <bug-followup@freebsd.org>
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
 

From: Daniel Eischen <deischen@freebsd.org>
To: Christopher Sean Morrison <brlcad@mac.com>
Cc: bug-followup@freebsd.org
Subject: Re: kern/86029: undefined reference to `_thread_dump_info'
Date: Wed, 21 Sep 2005 13:51:13 -0400 (EDT)

 On Wed, 21 Sep 2005, Christopher Sean Morrison wrote:
 
 > The issue is not with libpthread  (i.e. -lpthread) but with the
 > -pthread option to gcc.  The symbol itself is provided via libc_r, not
 > libpthread.  As the bug report notes, everything works if I link
 > against -lc_r which was unexpected when already passing -pthread.
 
 I've already responded to this in a previous email.  -pthread
 is doing what it is suppose to, and you shouldn't be using libc_r
 on 5.x and subsequent because it is not the default threads
 library (and may be deprecated in the future).
 
 -- 
 DE
 

From: Christopher Sean Morrison <brlcad@mac.com>
To: Daniel Eischen <deischen@freebsd.org>
Cc: David Xu <davidxu@freebsd.org>, bug-followup@freebsd.org
Subject: Re: kern/86029: undefined reference to `_thread_dump_info'
Date: Wed, 21 Sep 2005 14:42:12 -0400

 On Sep 21, 2005, at 1:28 PM, Daniel Eischen wrote:
 
 > That's what SIGINFO is for.  Again, that's undocumented and
 > allowed to change, but it's better than calling a library
 > internal function.
 
 Again, this is really tangent to the whole point of the report, but it 
 does raise ab additional question.  If I raise a SIGINFO, is that going 
 to give identical detail about the current threading states?  I agree 
 that it's better means to the end.  The OpenBSD pthreads(3) manual page 
 does document the signal but I have not had a motivation to change/test 
 that bit of code until now.
 
 >> 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.
 
 Which has always been my understanding of -pthread as well.  Does this 
 mean then that the C library routines on an AMD64 FreeBSD 5.4 system 
 are supposed to be re-entrant and thread safe?  If that's the case, 
 then I probably have another bug report to make.  It also doesn't 
 explain the inconsistency with the same rev of FreeBSD on IA32 systems 
 where the same behavior is not exhibited.
 
 Cheers!
 Sean
 

From: Daniel Eischen <deischen@freebsd.org>
To: Christopher Sean Morrison <brlcad@mac.com>
Cc: David Xu <davidxu@freebsd.org>, <bug-followup@freebsd.org>
Subject: Re: kern/86029: undefined reference to `_thread_dump_info'
Date: Wed, 21 Sep 2005 15:07:16 -0400 (EDT)

 On Wed, 21 Sep 2005, Christopher Sean Morrison wrote:
 
 > On Sep 21, 2005, at 1:28 PM, Daniel Eischen wrote:
 >
 > > That's what SIGINFO is for.  Again, that's undocumented and
 > > allowed to change, but it's better than calling a library
 > > internal function.
 >
 > Again, this is really tangent to the whole point of the report, but it
 > does raise ab additional question.  If I raise a SIGINFO, is that going
 > to give identical detail about the current threading states?  I agree
 > that it's better means to the end.  The OpenBSD pthreads(3) manual page
 > does document the signal but I have not had a motivation to change/test
 > that bit of code until now.
 
 If you're debugging the threads library, you should be looking
 at its source.  SIGINFO just calls _thread_dump_info() (which
 is not exported in libpthread) and does the same thing.  But,
 SIGINFO was meant more for us to debug the thread library.
 
 > Which has always been my understanding of -pthread as well.  Does this
 > mean then that the C library routines on an AMD64 FreeBSD 5.4 system
 > are supposed to be re-entrant and thread safe?
 
 Of course.
 
 > If that's the case,
 > then I probably have another bug report to make.  It also doesn't
 > explain the inconsistency with the same rev of FreeBSD on IA32 systems
 > where the same behavior is not exhibited.
 
 I'm going to close this one.  You'll need something that
 easily regenerates your problem if you file another bug
 report on it.
 
 -- 
 DE
 

From: Christopher Sean Morrison <brlcad@mac.com>
To: Daniel Eischen <deischen@freebsd.org>
Cc: David Xu <davidxu@freebsd.org>, bug-followup@freebsd.org
Subject: Re: kern/86029: undefined reference to `_thread_dump_info'
Date: Thu, 22 Sep 2005 08:16:26 -0400

 On Sep 21, 2005, at 3:07 PM, Daniel Eischen wrote:
 
 > If you're debugging the threads library, you should be looking
 > at its source.  SIGINFO just calls _thread_dump_info() (which
 > is not exported in libpthread) and does the same thing.  But,
 > SIGINFO was meant more for us to debug the thread library.
 
 Good to know, sounds like that may be a better solution for this 
 particular situation and esoteric enough to not warrant maintaining the 
 _thread_dump_info() call in order to support older BSD systems that 
 perhaps predate or don't support the SIGINFO behavior.  For what it's 
 worth, this bit of code has in fact been used to debug the threading 
 libraries in the past.
 
 > I'm going to close this one.  You'll need something that
 > easily regenerates your problem if you file another bug
 > report on it.
 
 Thanks for your suggestions and insight.
 
 Cheers!
 Sean
 
State-Changed-From-To: open->closed 
State-Changed-By: deischen 
State-Changed-When: Thu Oct 6 22:15:55 GMT 2005 
State-Changed-Why:  
This interface is an internal interface, not public and is subject 
to change. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=86029 
>Unformatted:
