This is the mail archive of the
mailing list for the glibc project.
Re: Fixing namespace issues for variables
- From: Rich Felker <dalias at libc dot org>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Sat, 24 Oct 2015 02:13:25 -0400
- Subject: Re: Fixing namespace issues for variables
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1510222324130 dot 23141 at digraph dot polyomino dot org dot uk>
On Fri, Oct 23, 2015 at 12:12:22AM +0000, Joseph Myers wrote:
> We have some bugs where library functions use a global variable outside
> the namespace of some standards containing those functions, interfering
> with programs' own use of variables by that name. These are currently
> whitelisted in linknamespace.pl. I'll use signgam (bug 15421) as the
> example in what follows (ISO C includes lgamma but not signgam), but the
> same applies equally to other cases of this issue.
> Normally namespace issues could be fixed by making the problem symbol into
> a weak alias for an implementation-namespace symbol and using the
> implementation-namespace symbol internally. However, this doesn't work
> for data symbols.
> A non-PIC program using signgam - whether it defined its own copy with
> "int signgam;" or referenced libm's copy with "extern int signgam;" or via
> the declaration of signgam when <math.h> is included under some conditions
> - uses it with non-PIC code sequences appropriate to a copy of the
> variable located directly in that program. When the program is linked, it
> then defines a dynamic symbol signgam (at the appropriate symbol version
> from glibc), and the dynamic linker makes this preempt the signgam symbol
> from libm, so that all references to signgam from within libm end up
> referring to the copy from the main program (there may also be a copy
> relocation to copy the initializer from libm to the copy in the main
> program). If any reference from within libm uses a different name, that
> reference does not get preempted, meaning that the two symbols that were
> aliases when libm was linked are no longer aliases at runtime.
> So simply using aliases is not a solution in the case of data symbols.
> The solution I propose instead is as follows. math.h would (under
> appropriate feature test macros) do:
I don't follow. How is this any different from environ, timezone,
daylight, etc.? They are all handled correctly by an alias; when
linking produces copy relocations, the linker does the right thing
automatically and preserves the aliasing.
> extern int *__signgam_location (void);
> #define signgam (*__signgam_location ())
This is non-conforming. POSIX requries an extern object. Note that the
rule about being able to use the interface without including the
header applies to most of the interfaces in math.h.