• State Accepted Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 1 reply
  • Subscribers 119 subscribers
  • Views 19995 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

unknown symbol __aeabi_uldivmod is causing my kernel module not to load. Any ideas as to why I'm seeing this? I am using gcc 4.7.2 for both the compilation of the kernel and the kernel module.

Chris Adeniyi-Jones
Arm Employee Badge

I am compiling on an Exynos 5250-based board with Ubuntu filesystem.

gcc -v

Using built-in specs.

COLLECT_GCC=gcc

COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.7/lto-wrapper

Target: arm-linux-gnueabihf

Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.7.2-2ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared\

--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-lib\

stdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libitm --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --d\

isable-werror --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf

Thread model: posix

gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1)

Parents
  • +1 Arm Employee Badge

    Hi Chris,

    I've been pointed to this fairly detailed thread: http://comments.gmane.org/gmane.linux.ports.arm.general/9544

    Hopefully that should explain it, here's an extract from that thread:

    GCC will reference it if you have a 64-bit divide or modulus. IOW:

    unsigned long long divide_by_10(unsigned long long a)

    {

    return a / 10;

    }

    will reference a 64-bit by 64-bit divide. However, we can do a lot

    better in the kernel:

    unsigned long long divide_by_10(unsigned long long a)

    {

    do_div(a, 10);

    return a;

    }

    which will do a 64-bit by 32-bit divide - which is what virtually all

    cases really want to be doing.

    Hope this helps,

    Joe

Reply
  • +1 Arm Employee Badge

    Hi Chris,

    I've been pointed to this fairly detailed thread: http://comments.gmane.org/gmane.linux.ports.arm.general/9544

    Hopefully that should explain it, here's an extract from that thread:

    GCC will reference it if you have a 64-bit divide or modulus. IOW:

    unsigned long long divide_by_10(unsigned long long a)

    {

    return a / 10;

    }

    will reference a 64-bit by 64-bit divide. However, we can do a lot

    better in the kernel:

    unsigned long long divide_by_10(unsigned long long a)

    {

    do_div(a, 10);

    return a;

    }

    which will do a 64-bit by 32-bit divide - which is what virtually all

    cases really want to be doing.

    Hope this helps,

    Joe

Children
No data