This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug nptl/17629] New: put all symbols nptl_db looks up in the private namespace


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]