was: begin using attribute_hidden

Joakim Tjernlund joakim.tjernlund at transmode.se
Sun Nov 13 16:12:27 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 think you should name the macro similar to the C version, perhaps STRONG_ALIAS, so
that it is clear what the macro does.

> 
> 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)

Agree.

> 
> 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 think we should use strong_alias until we find it doesn't work for some reason. 
I guess glibc uses weak so you can several defs of the same function and let the linker
select which one to use, but I am only guessing here.

> 
> 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




More information about the uClibc mailing list