kern/86029: undefined reference to `_thread_dump_info'

[Daniel Eischen]

The following reply was made to PR kern/86029; it has been noted by GNATS.

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