This is the mail archive of the libc-alpha@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]

Re: [BZ#17090/17620/17621]: fix DTV race, assert, and DTV_SURPLUS Static TLS limit


On 11/20/2014 02:17 AM, Roland McGrath wrote:
> In actual fact, GDB ignores the argument entirely and just does a vanilla
> symbol lookup like you'd get if you said "p &symbol".  That's why it works
> at all now for statically-linked libpthread, where the main executable is
> where the symbols are actually found.  

Indeed.  I once tried to change GDB to actually use the passed in argument,
but found that broke the statically-linked libpthread case.

> That said, since the interface has
> the parameter, I'd still be in favor of passing in the correct object name
> just pro forma (since it's really not hard to implement).

Note that's really not sufficient for getting the statically-linked case
fully right.  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

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.

Thanks,
Pedro Alves


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