Re: undefined reference to __udivdi3 (gcc-4.3)

Segher Boessenkool wrote:
I assume it's one or both of these loops in arch/x86/xen/time.c do_stolen_accounting() that are being optimized into a divide which generates a libgcc call:

while (stolen >= NS_PER_TICK) {
ticks++;
stolen -= NS_PER_TICK;
}

or

while (blocked >= NS_PER_TICK) {
ticks++;
blocked -= NS_PER_TICK;
}

That looks plausible.

Yep. Probably both.

Not sure if that is a sustainable fix, though..

It should be. The asm() arg tells GCC that the asm() could modify
"ns" in some way, so GCC cannot optimise away the loop, since it
doesn't have the required info about the induction variable to do
that.

Yep, it's guaranteed to work. But it's an ugly hack to work around an over-enthusiastic compiler, and so is an inherent maintainability burden.

I think the correct fix here is to introduce an iter_div_rem() function which contains this hack, so we can avoid scattering it all over the place. I'll cook up a patch.

J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/