This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: libm error handling
- From: Rich Felker <dalias at aerifal dot cx>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Andreas Schwab <schwab at linux-m68k dot org>, Roland McGrath <roland at hack dot frob dot com>, libc-alpha at sourceware dot org
- Date: Wed, 1 May 2013 11:01:27 -0400
- Subject: Re: libm error handling
- References: <20130430181544 dot GG20323 at brightrain dot aerifal dot cx> <Pine dot LNX dot 4 dot 64 dot 1304301910460 dot 28945 at digraph dot polyomino dot org dot uk> <20130430195734 dot B5AB82C08F at topped-with-meat dot com> <20130430200511 dot GH20323 at brightrain dot aerifal dot cx> <20130430205519 dot C86632C088 at topped-with-meat dot com> <20130430213524 dot GJ20323 at brightrain dot aerifal dot cx> <m2a9of4r15 dot fsf at igel dot home> <20130430221230 dot GK20323 at brightrain dot aerifal dot cx> <m2sj27kw6c dot fsf at igel dot home> <Pine dot LNX dot 4 dot 64 dot 1305011010440 dot 1249 at digraph dot polyomino dot org dot uk>
On Wed, May 01, 2013 at 10:19:34AM +0000, Joseph S. Myers wrote:
> On Wed, 1 May 2013, Andreas Schwab wrote:
>
> > Rich Felker <dalias@aerifal.cx> writes:
> >
> > > Existing binaries with the copy relocation for signgam should not be
> > > broken by changing signgam to a weak alias for __signgam internally.
> >
> > Yes, they are, because libm no longer updates the real signgam.
>
> The lgamma at the old symbol version that writes to signgam (as opposed to
> the one at the new symbol version that writes to __signgam) would no
> longer update the real signgam (in the user's existing binary)? Or the
> one at the new symbol version, writing to __signgam, would not update the
> signgam that's present in a newly linked binary as a result of a copy
> relocation, even though it's required to do so for XSI conformance?
Existing binaries with signgam in the main program being a copy
relocation for the one in libm, and with references to the old symbol
version for lgamma, would invoke an lgamma wrapper that would store
the value of __signgam to the application's signgam.
Newly linked binaries would get the new version of lgamma which would
store the result in __signgam, but if they had an external unresolved
symbol named signgam, it would become a copy relocation for the weak
symbol signgam from libm.
I see no need for a new __lgamma_xsi symbol. It would only be needed
if the behavior of lgamma needed to depend on whether _XOPEN_SOURCE
was defined or not, and due to the way weak symbols work, such
behavior is not necessary. (The issue is the same as the ugly global
variables set by tzset and other timezone-related functions.)
Rich