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