Mike Frysinger wrote, regarding the minimal linux syscall patches: > to check for this, you can run `readelf -r` on the libc.so file and > look at all the function relocs. the only ones in that list you should > see are malloc related (malloc/free/calloc/etc...). if you see other > symbols, they're most likely missing the libc_hidden stuff.
I have nothing to do with those patches. (I don't trust the stability of dentry-based Linux kernels, so I run 2.0.40 and all this minimal syscall stuff is kind of irrelevant for me....) However, out of curiousity I ran readelf -r on my own uClibc executable, and I found more than just malloc-related functions. Besides 114 ".rel.dyn" entries and the malloc-related ".rel.plt"s, there were the following: __errno_location __h_errno_location __unix_grantpt _dl_app_init_array _dl_app_fini_array My version of uClibc is heavily patched from 0.9.33.2, but these functions don't relate to my changes. Although "__unix_grantpt" is probably wrong because I'm the only one exercising the "old PTYs available and new PTYs never available" code path. The other four could be normal. The "*_location" ones are probably for libpthread to override (but I've configured threads out). The "_dl_app_*" ones have no local definition and are definitely there for override by ldso. On a related note: It appears the reason malloc and friends are exceptions to the general rule is to support applications that want to wholly replace the malloc engine with a custom one. But that feature is not often used. It would be nice if there was a configuration option to not treat malloc specially, and also to make brk() and sbrk() invisible. I don't think those two functions were ever part of the original POSIX 1992, and they are obsolete in the more recent standards. It could save a few bytes. ---- Michael Deutschmann <[email protected]> _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
