Hi all,
Just as the mail title, recently on RISC-V 32bit platform, I've been
encountering linking errors when building a certain part of Kernel,
`fs/ext4/extents.c`, without optimization (-O0) for debugging .
The error message GNU ld giving out indicates that it fails to resolve
undefined symbol "__divdi3", which is one of integer library routines
shipped by libgcc.
After conducting an autopsy, I can locate the root cause is that the
roundup() macro, which does division on 64bit data, is used inside
`fs/ext4/extends.c:elf_core_dump()`. Unfortunately, it's highly unlikely
to fit 64bit data into instruction encoding space on 32bit machines,
hence GCC will try to use its own software routines inside libgcc and
causing the linking error mentioned above.
Yet with default optimization level "-O2", the logic could be optimized
into bitwise instructions ("shift" and "and").Thus the linking error
won't occur.
Though I can kludge the build process by modifying
`scripts/link-vmlinux.sh:vmlinux_link()` to force it link kernel
against libgcc.a, still I'm wondering if it's desirable to work this
issue out by either :
(1) replacing `roundup()` with `round_up()` since `ELF_EXEC_PAGESIZE`
must be the power of 2. (The attached patch.)
or
(2) duplicate the logic from `roundup()` and use kernel-provided
`div_s64()` instead of plain division. The most recent relating patch I
saw is 013ad043, which takes this approach.
In my humble opinion, even it's understandable to expect a reasonable
level of optimization in the real world just as glibc expects at least "-Og"
is used, still, I feel absurd to depends on the optimization on
"replacing division with shift and and" to save the day.
Cordially yours,
Ruinland
--
2.17.1
