One annoyance of GCC 4.3.x on uClibc is that it links libgcc_s into every single executable and library it produces. This is because of the exception support -- code in crtbegin.o tries to register "unwind info" using a function deliberately absent from the static libgcc.
Glibc users are apparently spared this -- on that platform libgcc_s can use the function "dl_iterate_phdr" from ld.so to retrieve the unwind info from the executable as it needs it, with no explicit registration required. Thus, libgcc_s only needs to be linked for code that actually throws or catches exceptions -- libraries that merely pass them through don't need it. I've noticed that the supposedly glibc-specific code, in fact is active on the uClibc platform. But GCC does the manual registration as well if being built for uClibc: (from gcc-4.3.2/gcc/crtstuff.c) > /* uClibc pretends to be glibc 2.2 and DT_CONFIG is defined in its link.h. > But it doesn't use PT_GNU_EH_FRAME ELF segment currently. */ > # if !defined(__UCLIBC__) \ > && (__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ > 2) \ > || (__GLIBC__ == 2 && __GLIBC_MINOR__ == 2 && defined(DT_CONFIG))) > # define USE_PT_GNU_EH_FRAME > # endif As an experiment, I built gcc-4.3.2 with the "!defined(__UCLIBC__)" diked out. I rarely use C++, but a simple exception test with an exception thrown from one .o file and caught in another seemed to work correctly. So, it seems I should report this as a bug in gcc-4.3.2, asking them not to treat uClibc as different from glibc in this regard. The present behavior is costly -- it bloats all executables. But before I do, I thought I should check here to see if anyone knew of a reason it is unsafe for GCC to rely upon uClibc's dl_iterate_phdrs. ---- Michael Deutschmann <[email protected]> _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
