thanks, this is enough information for me to understand and propose you a solution.
it turns out that I can trivially compile and run a program that contains the example functions definitions you gave previously. this picked my curiousity and took a deeper look at how things work and are built in our platform. and boy, do things look a bit different from what I thought initially. - all the __aeabi_ functions are part of a companion library called "libgcc" (http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html) that comes with your toolchain. more exactly, your toolchain comes with several versions of libgcc, which depend on which compiler options you're using. the one we used is the one returned by the following command: arm-none-linux-gnueabi-gcc -mthumb-interwork -print-libgcc-file-name - when you create an executable (either static or dynamic) *or* a shared library, link it to this libgcc.a. this means that the aeabi functions required by the executable/library are directly copied into it. yes, this also means that these functions will be duplicated in the process space of a program that links to several shared libraries requiring them. note that libgcc.a must appear last in your link command. this explains why there are some eabi functions in the C library, but not all of them, or in the linker, or in many other libraries. these multiple definitions will not conflict since the linker will resolve the symbol to the first one it finds when needed (and all functions are identical). My belief that the linker provided all the functions and linked them at runtime was essentially wrong. I don't know exactly why we're doing it this way, but I'll ask the system guys. My first guess would be that we do that mainly for performance reasons (a direct function call is significantly faster than a PLT trampoline jump, even after lazy relocation being performed, and many of these functions are tiny but crucial for 64-bit support, floating-point emulation, and even straight integer division) On Mon, Mar 31, 2008 at 3:54 AM, David Given <[EMAIL PROTECTED]> wrote: > > Digit wrote: > > we have our own C library that we wrote by porting parts of the BSD C > > library on top the Linux kernel. > > but it conforms to the ARM EABI and you can trivially see that our own > > system libraries refer to these kind of symbols dynamically too. > > Okay, here's some C code that provokes this: > > ---snip--- > unsigned int f2uiz(float f) { return (unsigned int) f; } > signed long long lasr(signed long long v, int s) { return v >> s; } > unsigned long long llsr(unsigned long long v, int s) { return v >> s; } > unsigned long long llsl(unsigned long long v, int s) { return v << s; } > ---snip--- > > Each function, when compiled, generates a call to the appropriate > __aeabi_* function: > > ---snip--- > f2uiz: > stmfd sp!, {r4, lr} > bl __aeabi_f2uiz(PLT) > ldmfd sp!, {r4, pc} > ---snip--- > > However, the libc contains only the following _aeabi_f2* functions: > > __aeabi_f2d > __aeabi_f2iz > __aeabi_f2lz > __aeabi_f2ulz > > __aeabi_f2uiz is documented in ARM's ABI helper function document > ( > http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043a/IHI0043A_rtabi.pdf > ). > > I'm compiling the code above with: > > arm-none-linux-gnueabi-gcc -std=c99 -Os -fPIC test.c -o test.s -S > -mcpu=arm926ej-s > > I'm getting the list of symbols from the libc with: > > arm-none-linux-gnueabi-gcc -T libc.so > > Is this enough information to duplicate, or is there anything else you > need? (And would this be better off on -internals?) > > -- > David Given > [EMAIL PROTECTED] > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] Announcing the new M5 SDK! http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
