This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] [BZ #18970]: Reference of pthread_setcancelstate in libc.a
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 17 Sep 2015 15:03:53 -0700 (PDT)
- Subject: Re: [PATCH] [BZ #18970]: Reference of pthread_setcancelstate in libc.a
- Authentication-results: sourceware.org; auth=none
- References: <20150917152135 dot GA25716 at intel dot com> <20150917195803 dot E05DF2C3B40 at topped-with-meat dot com> <CAMe9rOrGYk6s94vvSVC1R7uBS-qGZaH8Pdwr62G+ZZdgnLKeig at mail dot gmail dot com> <20150917215151 dot 6201A2C3B40 at topped-with-meat dot com> <alpine dot DEB dot 2 dot 10 dot 1509172152540 dot 2455 at digraph dot polyomino dot org dot uk>
> On Thu, 17 Sep 2015, Roland McGrath wrote:
>
> > > Is this a valid test?
> >
> > No. There should be no need for individual tests like that. The
> > linknamespace tests should catch such things if the conform data is correct
> > (and if it's not, the right thing is to fix the conform data).
>
> See one of the caveats listed in linknamespace.pl:
>
> # * Weak undefined symbols are ignored; however, if a code path that
> # references one (even just to check if its address is 0) is executed,
> # that may conflict with a definition of that symbol in the user's
> # program.
Ah. That is something to be concerned with.
That being the case, HJ's test is probably about right (but needs comments).
> I don't know what combination of false positives and real problems you'd
> find if linknamespace.pl stopped special-casing weak symbols.
I think we should look into that. The name space issues are orthogoal to
weakness in all scenarios I can think of. If code reached by function foo
is affected at all by a symbol bar and bar is in the application name space
for some application that can use foo, then there is a problem.
> > AFAIK fmtmsg is only specified in standards that put all POSIX.1 symbols
> > (including pthread_setcancelstate) in the implementation name space.
>
> fmtmsg is in XPG4, which doesn't have pthreads.
In that case the fix is actually necessary. Thanks for pointing that out.
Thanks,
Roland