0

I'm trying to cross-compile a kernel module for Raspberry. In this module, I need to divide two 64 bits unsigned int. The compilation works, but there's this warning : WARNING: "__aeabi_ldivmod" undefined !

And when I try to insmod the module, it obviously refuses to insmod, because of this undefined symbol.

Do you guys know how I can divide those 64 bits uints ?

PinkPR
  • 345
  • 5
  • 13
  • 2
    http://stackoverflow.com/questions/25623956/aeabi-ldivmod-undefined-when-compiling-kernel-module (first hit when Googling the error message) – Cody Gray - on strike Dec 29 '16 at 13:30
  • Yep, forgot to mention, but already tried this. Doesn't work, doesn't want to compile. Plus, do_div() has horrible side effects and I really don't want this. Then, it supports dividing 64 bits by 32 bits, but not 64 bits by 64 bits. – PinkPR Dec 29 '16 at 13:33
  • 1
    "Horrible side effects"? Like what? You cannot natively divide two 64-bit values on a 32-bit architecture. You'll need some kind of library that emulates the division, or you'll have to write such a function yourself. If the side effect is "slow", then yes. That's inevitable. – Cody Gray - on strike Dec 29 '16 at 13:36
  • It modifies the number you want to get divided ... I don't wanna have to save operands before applying the division :o – PinkPR Dec 29 '16 at 13:42
  • Then I'll have to implement something by myself .. – PinkPR Dec 29 '16 at 13:42
  • 2
    Oh no, ARM has only 16 registers and 4 of them are clobbered by function calls, whatever will you do! If a couple extra register-copy instructions are a problem, then obviously you should experiment with inlining the code from the 64-bit division function, or avoid doing a 64-bit division in the first place. (e.g. maybe experiment with a multiplicative inverse if the divisor is constant, even though that requires extended-precision multiplication). – Peter Cordes Dec 29 '16 at 14:09
  • 2
    Why don't you want to save operands before division? I can't see any reasonable problem with that... 1) memory-space: I bet you have 8 or 16 more bytes on stack. 2) performance: LOL (that 64b DIV will take probably 100x more time than save/restore of operands). 3) ... can't think of anything else. – Ped7g Dec 29 '16 at 14:15
  • Also see [64-bit division in ARM Assembly SOS](http://stackoverflow.com/q/26633800) and [64bit/32bit division faster algorithm for ARM / NEON?](http://stackoverflow.com/q/15215196), and [6.2.2. Multiply and divide instructions](https://developer.arm.com/docs/den0024/latest/6-the-a64-instruction-set/62-data-processing-instructions/622-multiply-and-divide-instructions) from the ARM Cortex-A guide if you are using ARMv8. – jww Dec 29 '16 at 14:28
  • "3) code size" .. but then this is "problem XY" question, because the need of 64b divide is sign of you being on detour anyway and what you are trying to do can be *very likely* done in simpler and shorter way (unless this is some cryptography task where you really need 64b correct exact divide, but that should be written in completely special way to keep constant execution time without branching for security reasons, so again saving operands would be least of the problems)... *now* I can't think of any more reasons... – Ped7g Dec 29 '16 at 14:49
  • find/grab the 64 bit division from the GCC sources, assemble it yourself and just call it, rename it as needed to avoid conflicts. Most likely your cross compile environment is not quite right. Can you build whatever you are building natively and not cross compiled? If so then it is simply your environment, your tools are not built right or not using the right paths, etc. Or maybe you found a case that simply cannot be cross compiled with this toolchain. – old_timer Jan 03 '17 at 06:45

0 Answers0