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

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

[palves at redhat dot com]

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.

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

[palves at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17629

--- Comment #1 from Pedro Alves <palves at redhat dot com> ---
Actually looks like "stack_used" may be the only one with the problem:

 $ grep -rn DB_GET_SYMBOL -rn
 nptl_db/td_ta_thr_iter.c:157:  err = DB_GET_SYMBOL (list, ta, __stack_user);
 nptl_db/td_ta_thr_iter.c:164:    err = DB_GET_SYMBOL (list, ta, stack_used);
 nptl_db/td_ta_tsd_iter.c:53:  err = DB_GET_SYMBOL (addr, ta, __pthread_keys);
 nptl_db/td_ta_event_addr.c:40:      err = DB_GET_SYMBOL (taddr, ta,
__nptl_create_event);
 nptl_db/td_ta_event_addr.c:44:      err = DB_GET_SYMBOL (taddr, ta,
__nptl_death_event);
 nptl_db/td_thr_validate.c:65:  err = DB_GET_SYMBOL (list, th->th_ta_p,
__stack_user);
 nptl_db/td_thr_validate.c:73:      err = DB_GET_SYMBOL (list, th->th_ta_p,
stack_used);
 nptl_db/td_ta_map_lwp2thr.c:190:  td_err_e err = DB_GET_SYMBOL (list, ta,
__stack_user);
 nptl_db/td_ta_set_event.c:41:  err = DB_GET_SYMBOL (eventmask, ta,
__nptl_threads_events);
 nptl_db/thread_dbP.h:150:#define DB_GET_SYMBOL(var, ta, name)                 
                       \
 nptl_db/td_thr_event_getmsg.c:71:  err = DB_GET_SYMBOL (prevp, th->th_ta_p,
__nptl_last_event);
 nptl_db/td_ta_clear_event.c:41:  err = DB_GET_SYMBOL (eventmask, ta,
__nptl_threads_events);

Though renaming __stack_user to __nptl_stack_user too might be good, in case
other parts of the implementation (e.g., libgcc) might end up defining their
own unrelated static symbols with that name too.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[palves at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17629

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |9635

-- 
You are receiving this mail because:
You are on the CC list for the bug.