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 10:28 AM, Pedro Alves wrote:
> 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.

FYI, filed PR17629 for this now.

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

Thanks,
Pedro Alves

> 
> 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]