Am I doing something wrong or there's a problem with libgcc? I'm compiling code for an ARM based micro. I'm using gcc 4.5.1, configured for arm-eabi-none, C compiler only. The target is a standalone embedded device, no OS, nothing, not even a C library, just bare metal. The compiler (and linker, gcc is being used to start the linker) get the -ffreestanding -static -static-libgcc -nostdlib flags.
Everything works fine until I want to do a 64-bit division. Then the linking fails, telling me that I have undefined references to memcpy, abort, __exidx_start and __exidx_end. Telling the linker to create an output despite the missing references reveals that the resulting object file contains the actual 64-bit division from libgcc, as expected. Plus it also contains about 4KB worth of functions related to unwinding, which are never referenced anywhere (i.e. the libgcc division routine does not call or use *any* of the functions there). There is all sorts of code in there to deal with the (nonexistent) float-point coprocessor, throwing exceptions and other magic. So, a function containing a single call to __aeabi_uldivmod results in about 4 KB unused code being sucked in from libgcc.a (some of which could not even be executed by the target processor), with 4 undefined references, of which __exidx_start and __exidx_end are, as far as I know, not even standard library functions. Is this a bug in libgcc, have I massiviley misconfigured the compilation of gcc itself or am I doing something horribly wrong but can't see the obvious? Zoltan
