RFC: use of hidden_def/hidden_proto

[Peter S. Mazinger]

Hello!

I would want to begin using hidden_def/hidden_proto and related 
lib*_hidden_* within uClibc as glibc(libc-symbols.h) does instead of the 
current practice in uClibc that looks like:

attribute_hidden __func() {}
strong_alias(__func,func)

and #define func __func at the top of the *.c files, where func is in use 
(some of the __func prototypes that are used more than 5 times are defined 
if possible in libc-internal.h and the users are changed from func to 
__func within *.c)

the glibc variant does

func() {}
lib*_hidden_def(func) (really creating a strong hidden alias __GI_func)

and uses lib*_hidden_proto(func) for the *.c where func is used (done 
in some internal headers), so that *.c will use the internal name of func 
(eg. __GI_func)

The change would imply to change all #define func __func (or partly 
__func_internal , where we also need __func visible) lines in *.c to 
libc_hidden_proto(func) and revert to the earlier definitions of func() 
(removing attribute_hidden), but appending after func 
libc_hidden_def(func)

Nothing to loose:
1. source code size and resulting object sizes remain the same
2. files overtaken from glibc need only libc_hidden_proto(func) for each 
internal function that we want to be used with its internal name (this 
can't be avoided due to the different header handling within glibc and 
uClibc, glibc uses a set of internal headers that include the ones that 
are finally installed on target and they put the internal prototypes 
there)

Benefits:
1. for those not wanting to use the feature to remove the jump relocations 
size of objects remains the same (currently if we set attribute_hidden to 
empty, the code size will have duplicates: __func and func, where only one 
is needed and making attribute_hidden empty will malfunction for PIC code 
in some code - eg. __syscall_error)
2. correct handling of __REDIRECT from func() to func64(), because the 
original header will do the redirection, libc_hidden_proto(func) will then 
convert either func or func64 to its internal naming (that we can agree or 
change within libc-internal.h if __GI_func is not ok, although we could 
stay with it, because gdb has gotten support for it - gdb ignores 
__x,__libc_x,__GI_x, noone else cares about these) (see how it has to be 
done currently in libc-internal.h for __*64 duplicating the REDIRECT code 
for __func[64])
3. we do not have to duplicate prototypes for __func and take care of them 
later if we update/modify the original header that carries func, because 
libc_hidden_proto(func) will do it for us internally. There are currently 
more then 500 prototypes that would have to be duplicated if done 
correctly without the #define func __func hack (that can't be used for any 
func that has func64 equivalent)
4. allows later easy switch to versioned lib support
5. makes it easier to use internal versions even if macros are used 
(currently almost impossible to track, I have lost about a week for 
__fgetc_unlocked for ex. and havent found a solution for it yet due to 
the many aliases and redefines).
6. allows a proper and consistent naming even for __func that need to stay 
visible
7. the same procedure can be used for other libs (not only libc) and it 
allows for files that are compiled both in libc and libpthread for ex. to 
have different usages.
To make this understandable lets take an ex. locale.c exists within libc 
and libpthread. We could have only one version and compile it for both 
libs.
using libc_hidden_def(__curlocale) means create a hidden version to be 
used within libc if built within libc, if built for libpthread the hidden 
version is not created.

Thanks reading so far, 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