attribute_hidden - semi-final results

Peter S. Mazinger ps.m at gmx.net
Thu Dec 15 20:54:11 UTC 2005


Hello!

vanilla 0.9.28
jump   text	   data	    bss	    dec	    hex	filename
531 281639	   4276	  19096	 305011	  4a773	lib/libuClibc-0.9.28.so
82  58029	    536	      4	  58569	   e4c9	lib/libm-0.9.28.so
10   8474	    232	  70940	  79646	  1371e	lib/libcrypt-0.9.28.so
27   3295	    300	      0	   3595	    e0b	lib/libutil-0.9.28.so

svn w/ attribute_hidden as noop
513 293704	   4264	  19120	 317088	  4d6a0	lib/libuClibc-0.9.28.so
85  59081	    556	      4	  59641	   e8f9	lib/libm-0.9.28.so
10   8479	    240	  70940	  79659	  1372b	lib/libcrypt-0.9.28.so
27   3356	    308	      0	   3664	    e50	lib/libutil-0.9.28.so

svn w/ enabled attribute_hidden
26 263939	   2256	  19120	 285315	  45a83	lib/libuClibc-0.9.28.so
56  57401	    440	      4	  57845	   e1f5	lib/libm-0.9.28.so
8   8367	    232	  70940	  79539	  136b3	lib/libcrypt-0.9.28.so
25   3264	    300	      0	   3564	    dec	lib/libutil-0.9.28.so

Most of the work was done within libuClibc, the others where only touched 
where it was obvious.
Some other configs are down below 20 for libuClibc.

The remaining stuff is:
a. tolower/toupper and friends depending on the config
These were not converted, because they are within macros, or are used 
mixed within the sources, once the macro, once the function.
b. malloc/realloc/calloc/free/memalign, these seems to be specially 
handled in glibc, so I haven't touched them due to big differences
c. memmove/memcpy partly, this is a compiler issue, some compilers get rid 
of memmove, some not, it could be a similarity w/ gcc "optimizing away"
memcmp within kernel if built w/ -Os
d. __errno_location, __h_errno_location (the latter could maybe go away)
e. *sig*, I don't touch these,  at least until new linuxthreads is 
committed, again due to mixup of macros and functions.
f. __pthread_mutex_* __pthread_once, __pthread_initialize_*
g. __longjmp, this is in almost each object, I have no idea how to get rid 
of it, I can't see how glibc got away with it
h. __uClibc_init (needed probably by ldso), we could maybe create a hidden 
one, return that in a visible one, and run the visible one from ldso

I will revert for now a change to __libc_fork/__libc_open used 
internally in __uClibc_main, so that it will work as the vanilla 0.9.28.
I will also revert sigaction for sure and maybe some other *sig* to get 
the earlier behaviour, until the cancelable syscalls case/future is 
clarified (no answer to my related mails, no opinions?)

Please someone take care of tolower/toupper if locales are not enabled and 
__ctype_b_loc/__ctype_toupper_loc/__ctype_tolower_loc.

Is it necessary that pthreads has own __curlocale[_set]? Does this have 
to overwrite the one in libc or they are only internal to each lib?

How to handle x() and x64() internally? Can it be assumed, that if not 
otherwise/explicitely specified, then if LFS is enabled use x64(), else 
x()? Can it be assumed, that in any y64.c file we use x64() and in 
the y.c file x()?

My last commits that reflect the state will be done within the next 
hours (have commit problems)

Thanks for your patience and understanding, 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