RFC: was: begin using attribute_hidden

Peter S. Mazinger ps.m at gmx.net
Sat Nov 12 11:07:57 UTC 2005


On Mon, 7 Nov 2005, Peter S. Mazinger wrote:

> > > What about start using attribute_hidden like:
> > > 
> > > attribute_hidden __x () {
> > > }
> > > 
> > > strong_alias(__x,x)
> > 
> > hehe, I just replied to your previous mail, suggesting this :)
> 
> Found this in a glibc internal header , could be used here too
> 
> /* The following macros are used for PLT bypassing within libc.so
>    (and if needed other libraries similarly).
>    First of all, you need to have the function prototyped somewhere,
>    say in foo/foo.h:
> 
>    int foo (int __bar);
> 
>    If calls to foo within libc.so should always go to foo defined in libc.so,
>    then in include/foo.h you add:
> 
>    libc_hidden_proto (foo)
> 
>    line and after the foo function definition:
> 
>    int foo (int __bar)
>    {
>      return __bar;
>    }
>    libc_hidden_def (foo)
> 
>    or
> 
>    int foo (int __bar)
>    {
>      return __bar;
>    }
>    libc_hidden_weak (foo)
> 
>    Simularly for global data. If references to foo within libc.so should
>    always go to foo defined in libc.so, then in include/foo.h you add:
> 
>    libc_hidden_proto (foo)
> 
>    line and after foo's definition:
> 
>    int foo = INITIAL_FOO_VALUE;
>    libc_hidden_data_def (foo)
> 
>    or
> 
>    int foo = INITIAL_FOO_VALUE;
>    libc_hidden_data_weak (foo)
> 
>    If foo is normally just an alias (strong or weak) of some other function,
>    you should use the normal strong_alias first, then add libc_hidden_def
>    or libc_hidden_weak:
> 
>    int baz (int __bar)
>    {
>      return __bar;
>    }
>    strong_alias (baz, foo)
>    libc_hidden_weak (foo)
> 
>    If the function should be internal to multiple objects, say ld.so and
>    libc.so, the best way is to use:
> 
>    #if !defined NOT_IN_libc || defined IS_IN_rtld
>    hidden_proto (foo)
>    #endif
> 
>    in include/foo.h and the normal macros at all function definitions
>    depending on what DSO they belong to.

looking more at glibc and headers, also uClibc's sparc/x86_64 asm code in 
libc/string, I wonder if we should use ENTRY/END as shortcuts, maybe 
modified, so that we have
ENTRY(memset,__memset), that would define __memset as hidden and set up a 
strong_alias to memset (ENTRY could check if it has 2 args, if there is 
only one, it behaves "normally")

I can't find in glibc when/why something is strong_alias, most of the time 
they go with weak_alias, so how should we proceed for uClibc?

I think that all __x() should be hidden (not visible at all in user 
space, although some headers show these unconditionally as visible, 
like __bcopy, but we could comment these out of headers, this could though 
be some historical issue) and x a strong_alias (only this should be visible)

Or we go w/ strong_alias for all ANSI/ISO or SuSv3, the others weak_alias?
What should be really overridable by an app, only glibc extensions?

glibc cares about backward compatibility that we do not have to consider.

I would want here a consistent procedure for uClibc (that does not really 
have to mimic in all regards glibc), please comment before I begin to
switch internally libc to use only/exclusively __x() for less relocations 
(faster code) and/or smaller size.

Thanks, Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2




More information about the uClibc mailing list