missing symbol __ucmpdi2 in kernel_x86

[mmu_man]

When trying to load a driver build in zeta (not sure R5 has it though, but I suppose it did):

KERN: "/boot/home/config/add-ons/kernel/drivers/dev/oss": could not resolve symbol '__ucmpdi2'

Seems it's missing from the libc runtime linked to the kernel:

[revol@Zeta /Data/haiku/trunk]# nm /haiku/beos/system/kernel_x86 |grep cmpdi
800936e0 T __cmpdi2
[revol@Zeta /Data/haiku/trunk]# nm /boot/beos/system/kernel_intel |grep cmpdi
00076fc0 T __cmpdi2
00077000 T __ucmpdi2

Seems it's present in R5-bone as well, so...

[mmu_man]

it seems it is present in libgcc.a, at least in my gcc... I think libgcc.a should be linked in fully, with the --whole-archive ld arg, else it results in only needed symbols being linked in. Not sure how to do it with jam... probably have to change KernelLd rule.. or maybe the ldscript ? I suppose SEARCH_DIR(libgcc) tells to pick needed symbols in it, maybe changing it to INPUT() ?

[mmu_man]

Hmm, didn't work. Changing KernelLd to do this:

LINKLIBS on $(1) = $(TARGET_STATIC_LIBSUPC++) --whole-archive $(TARGET_GCC_LIBGCC) ;

did the thing, but linking fails as it requires other symbols like fread, fwrite, which are useland stuff... I suppose we need to force the symbol in but not the whole archive.

[mmu_man]

adding an

EXTERN(__ucmpdi2)

in the kernel ld script seems to do the job... not sure it's the best way though. comments ?

[bonefish]

ATM, it's as easy as that: Kernel modules requiring libgcc features just link against libgcc directly.

[mmu_man]

Except this module was compiled in BeOS. This means bin compatibility is broken.

[mmu_man]

Hmm ok, it seems more logical to link libgcc in, as it might change with gcc versions anyway. I suppose the exported symbol on R5 was probably just a side effect of something needing it in the kernel itself.