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