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