This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fixing namespace issues for variables
- From: Florian Weimer <fweimer at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 23 Oct 2015 12:06:35 +0200
- 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 10/23/2015 02:12 AM, Joseph Myers wrote:
> 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:
>
> extern int *__signgam_location (void);
You could add __attribute__ ((pure)), I think.
> #define signgam (*__signgam_location ())
>
> __signgam_location would be a new dynamic symbol exported from libm. The
> existing signgam export from libm would become a compat symbol.
>
> In static libm, and shared libm for new ports, the variable signgam would
> simply be renamed to __signgam, and we'd have:
>
> int *
> __signgam_location (void)
> {
> return &__signgam;
> }
For real global variables, this isn't pretty, but I think it is
acceptable (if the ELF specifics work out, including size changes, which
I don't know). Such global variables are legacy anyway due to thread
safety, so the additional performance overhead would not matter.
Constants are another matter. We might need something else for them if
applications can expect fast access.
Florian