From: Pedro Alves <palves@redhat.com>
To: Roland McGrath <roland@hack.frob.com>,
Alexandre Oliva <aoliva@redhat.com>
Cc: libc-alpha@sourceware.org
Subject: Re: [BZ#17090/17620/17621]: fix DTV race, assert, and DTV_SURPLUS Static TLS limit
Date: Thu, 20 Nov 2014 10:28:00 -0000 [thread overview]
Message-ID: <546DC230.6000401@redhat.com> (raw)
In-Reply-To: <20141120021703.86F032C3B18@topped-with-meat.com>
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
next prev parent reply other threads:[~2014-11-20 10:28 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-18 19:58 Alexandre Oliva
2014-11-18 20:33 ` Roland McGrath
2014-11-18 22:09 ` Alexandre Oliva
2014-11-18 22:40 ` Roland McGrath
2014-11-19 19:57 ` Alexandre Oliva
2014-11-20 2:17 ` Roland McGrath
2014-11-20 6:48 ` Alexandre Oliva
2014-11-20 18:14 ` Torvald Riegel
2014-11-21 8:28 ` Alexandre Oliva
2014-11-21 13:48 ` Alexandre Oliva
2014-12-09 18:45 ` Alexandre Oliva
2015-01-06 0:06 ` Alexandre Oliva
2015-02-26 5:44 ` Alexandre Oliva
2015-03-04 5:05 ` Alan Modra
2015-03-04 11:04 ` Alan Modra
2015-03-05 17:14 ` Alexandre Oliva
2015-03-05 17:25 ` Szabolcs Nagy
2015-03-05 23:39 ` Alexandre Oliva
2015-03-06 2:05 ` Alexandre Oliva
2015-03-16 19:01 ` Richard Henderson
2015-03-17 4:34 ` Alexandre Oliva
2015-03-18 14:46 ` Szabolcs Nagy
2015-06-09 7:11 ` Alexandre Oliva
2015-06-09 10:12 ` Szabolcs Nagy
2015-11-23 15:15 ` Aurelien Jarno
2016-09-15 14:51 ` Andreas Schwab
2016-09-23 15:22 ` Alexandre Oliva
2016-09-23 20:40 ` Florian Weimer
2016-09-24 2:53 ` Alexandre Oliva
2016-09-24 10:53 ` Torvald Riegel
2016-09-25 22:10 ` Alexandre Oliva
2016-09-29 11:27 ` Torvald Riegel
2016-09-29 22:09 ` Alexandre Oliva
2016-09-30 9:23 ` Torvald Riegel
2014-11-20 10:28 ` Pedro Alves [this message]
2014-11-20 11:48 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=546DC230.6000401@redhat.com \
--to=palves@redhat.com \
--cc=aoliva@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=roland@hack.frob.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).