While tinkering with local toolchains and reading the tea leaves, I found some suspicious naming in arch/x86/lib/gcc.c

In arch/x86/lib/config.mk, I see: LDFLAGS_FINAL += --wrap=__divdi3 --wrap=__udivdi3 LDFLAGS_FINAL += --wrap=__moddi3 --wrap=__umoddi3

Per man ld [http://linux.die.net/man/1/ld], --wrap=_Foo will: 1. Divert all references to _Foo to __wrap_Foo 2. Expose the underlying _Foo as __real_Foo.

However, the WRAP_LIBGCC_CALL macro in that code appears to assume the underlying _Foo will be exposed as __normal_Foo.

#define WRAP_LIBGCC_CALL(type, name) \ type __normal_##name(type a, type b) __attribute__((regparm(0))); \ type __wrap_##name(type a, type b); \ type __attribute__((no_instrument_function)) \ __wrap_##name(type a, type b) \ { return __normal_##name(a, b); }

Does anyone rely on this breakage? It does generate ld errors where the code attempts dangerous glib calls, from which you can switch in do_div and fiends.

If the idea is to avoid relying on 64 / 64 divides, I can send a patch for the ones I found this way. Assuming they're not fixed by the time I get there.

And / or I can send a patch to look for __real___udivdi3 rather than __normal___udivdi3, assuming that's the right idea.

Apologies for the noise if I'm merely holding it wrong, -- peterh