Date: Wed, 21 Sep 2005 15:00:28 GMT From: Christopher Sean Morrison <brlcad@mac.com> To: freebsd-threads@FreeBSD.org Subject: Re: kern/86029: undefined reference to `_thread_dump_info' Message-ID: <200509211500.j8LF0SBD029711@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/86029; it has been noted by GNATS. 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200509211500.j8LF0SBD029711>