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