On Mon, 2011-09-05 at 12:10 +0200, Norman Feske wrote: > Codezero expects the tool chain to be used for the kernel to not support > shared libraries. (this is the case for Codesourcery's arm-none-eabi > tool chain) Such tool chains use to incorporate both libgcc and > libgcc_eh into the single libgcc.a library. In contrast, for tool chains > built with '--enable-shared', libgcc does not contain the functions of > libgcc_eh. Hence, one symbol called '__aeabi_unwind_cpp_pr0' referenced > by libgcc and normally provided by libgcc_eh remains unresolved. > > There are two possible solutions for this problem: We could link > libgcc_eh to the 'final.elf' image as expected by libgcc. However, this > way, we will need to implement the the environment expected by > libgcc_eh. For Codezero, this is pointless because no C++ is used. The > second option is to provide a dummy symbol for '__aeabi_unwind_cpp_pr0' > just to make the linker happy. This patch adds such a dummy symbol to > 'loader/main.c'. (admittedly, 'main.c' is not the perfect location for > this symbol - so maybe we should provide the symbol in another way?) > > Using this patch, the kernel can be built with fully-fledged tool > chains. Consequently, the currently used two tool chains can then be > replaced by a single one.
Ack. Looks good, but I think libc is a better place for this as that is used both by loader and userspace. Also, we one of our goal is to improve libc, so as the user can link with that only and use only none-eabi- toolchain for userapps too. -- Thanks Amit Mahajan _______________________________________________ codezero-devel mailing list codezero-devel@lists.l4dev.org http://lists.l4dev.org/mailman/listinfo/codezero-devel_lists.l4dev.org
