[BZ#17090/17620/17621]: fix DTV race, assert, and DTV_SURPLUS Static TLS limit
Pedro Alves
palves@redhat.com
Thu Nov 20 11:48:00 GMT 2014
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
>
More information about the Libc-alpha
mailing list