What is the cause of not being able to divide numbers in GCC

i'm having a very strange situation. Every time I try to compile my arm project (LPC2378, codesourcery arm-none-eabi-gcc-4.5.1) I am left with the same error whilst linking

/media/data/Projects/arm/uart/main.c:39: undefined reference to `开发者_运维知识库__aeabi_uidiv'
/media/data/Projects/arm/uart/main.c:40: undefined reference to `__aeabi_uidiv'

The offending code looks like this:

U0DLL = ((((PLLCFG & 0x7FFF) + 1) * F_OSC) / ((((PLLCFG & (0xFF << 16)) >> 16) + 1) * ((CCLKCFG & 0xFF) + 1) * 8 * BAUD * 1)) % 256;
U0DLM = ((((PLLCFG & 0x7FFF) + 1) * F_OSC) / ((((PLLCFG & (0xFF << 16)) >> 16) + 1) * ((CCLKCFG & 0xFF) + 1) * 8 * BAUD * 1)) / 256;

I've searched around and what this can be caused by, AFAICT, not using lgcc & lc options for LD. I've resolved that and still the error remains.

The full project can be found at my github repo.

If anybody could help it would be greatly received. Cheers.

The ARM family of CPUs does not have a native integer division instruction. So, division needs to be implemented by a library function. GCC knows this, and creates a reference to (in your case) __aeabi_uidiv (for unsigned int division).

You will need to link with an appropriate runtime support library that contains this function.

I faced this issue and resolved it by passing the proper location of the libgcc.a in the Makefile. You may have to add:

"-L*path_to_libgcc.a* -lgcc" 

to LDFLAGS

Sounds like a toolchain problem - perhaps your gcc is built for ARM EABI but your libraries (libgcc?) were built for traditional ABI?

I normally avoid divides, when I have to use one, sometimes I hit this problem. The (assembler) source for those division functions are in the gcc sources, not too hard to extract that code and just link it in when gcc doesnt cooperate. Once you have a version with the macros removed, etc, a clean source, you can just carry that around in your back pocket. Googling I had found at one time that the suggestion was to use the non linux eabi, but as you have found that doesnt always work, sometimes but not always.

Check, whether your libgcc.a resides in the codesourcery directory where it should be. I had the same issue with TI starterware, which fixed the path to libgcc.a in one of the makefiles.