This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fixing namespace issues for variables


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.

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]