This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/17629] New: put all symbols nptl_db looks up in the private namespace
- From: "palves at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Thu, 20 Nov 2014 11:44:07 +0000
- Subject: [Bug nptl/17629] New: put all symbols nptl_db looks up in the private namespace
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=17629
Bug ID: 17629
Summary: put all symbols nptl_db looks up in the private
namespace
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: nptl
Assignee: unassigned at sourceware dot org
Reporter: palves at redhat dot com
CC: drepper.fsp at gmail dot com
Ref: https://sourceware.org/ml/libc-alpha/2014-11/msg00534.html
Consider the statically-linked libpthread case, where the main executable is
where the libpthread symbols are actually found.
Some of the libpthread symbols thread_db wants to looks up, although static,
have names that aren't in the implementation namespace. As such, if the
statically-linked program happens to have other symbols with the same name, GDB
might well find and return those to nptl_db instead.
For example, it should be perfectly legitimate for a program to define a
symbol called "stack_used", but that ends up confusing nptl_db/gdb,
because that's one of the static libpthread symbols nptl_db looks up:
/* List of the stacks in use. */
static LIST_HEAD (stack_used);
And that's exactly what happened in:
[Bug 9635 - Cannot find new threads: generic error]
https://sourceware.org/bugzilla/show_bug.cgi?id=9635
--
You are receiving this mail because:
You are on the CC list for the bug.