kern/86029: undefined reference to `_thread_dump_info'

Christopher Sean Morrison brlcad at mac.com
Wed Sep 21 08:00:35 PDT 2005


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

From: Christopher Sean Morrison <brlcad at mac.com>
To: "Daniel M. Eischen" <eischen at vigrid.com>
Cc: bug-followup at 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.
 


More information about the freebsd-threads mailing list