This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [BZ#17090/17620/17621]: fix DTV race, assert, and DTV_SURPLUS Static TLS limit
- From: Pedro Alves <palves at redhat dot com>
- To: Roland McGrath <roland at hack dot frob dot com>, Alexandre Oliva <aoliva at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 20 Nov 2014 11:48:33 +0000
- Subject: Re: [BZ#17090/17620/17621]: fix DTV race, assert, and DTV_SURPLUS Static TLS limit
- Authentication-results: sourceware.org; auth=none
- References: <ormw7ol1sf dot fsf at free dot home> <20141118203338 dot ECA5F2C3B25 at topped-with-meat dot com> <ord28kkvpq dot fsf at free dot home> <20141118224048 dot 600312C3B23 at topped-with-meat dot com> <orppcjotfm dot fsf at free dot home> <20141120021703 dot 86F032C3B18 at topped-with-meat dot com> <546DC230 dot 6000401 at redhat dot com>
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
>
- References:
- [BZ#17090/17620/17621]: fix DTV race, assert, and DTV_SURPLUS Static TLS limit
- Re: [BZ#17090/17620/17621]: fix DTV race, assert, and DTV_SURPLUS Static TLS limit
- Re: [BZ#17090/17620/17621]: fix DTV race, assert, and DTV_SURPLUS Static TLS limit
- Re: [BZ#17090/17620/17621]: fix DTV race, assert, and DTV_SURPLUS Static TLS limit
- Re: [BZ#17090/17620/17621]: fix DTV race, assert, and DTV_SURPLUS Static TLS limit
- Re: [BZ#17090/17620/17621]: fix DTV race, assert, and DTV_SURPLUS Static TLS limit
- Re: [BZ#17090/17620/17621]: fix DTV race, assert, and DTV_SURPLUS Static TLS limit