From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.1-0.1.9 i686)
In the 2.4.2 kernel udelay is a macro that checks if you are attempting to
pass a delay of >20000 and calls a non-existant a bad_udelay() function.
The wavelan_cs module in drivers/net/pcmcia makes multiple calls to udelay
but never with a value greater than 100. Yet, the compiler is making the
calls to bad_udelay.
Steps to Reproduce:
1. Compile the 2.4.2 kernel sources with no patches
2. nm -B /usr/src/linux/drivers/net/pcmcia/wavelan_cs.o | grep bad_udelay
Actual Results: U __bad_udelay
Expected Results: Nothing
I remember fixing similar thing in gcc-2.96-72, are you sure you have say
2.96-75 or later?
If yes, can you please attach here wavelan_cs.i (add -save-temps -v options
to the gcc command which creates wavelan_cs.o) and also post full gcc command
line used? It maybe config related etc., by working on preprocessed output
we can be sure we're seeing the same thing. Thanks.
FYI I've just tried it and could not get __bad_udelay unresolved in any of
-march=i386, -march=i686, -march=k6 or -march=athlon. So, I really need your
feedback on this.
I WAS able to reproduce it consistently. I even tried applying the redhat
patches to the wavelan driver to see if changing the function from inline to a
macro made it better. It didn't. Today I've redone the compile several times and
I can't make bad_udelay occur. Maybe there's an uninitialized variable somewhere
and I can't reproduce the circumstances.
We (Red Hat) should really try to resolve this before next release.
If you are able to reproduce this, please reopen this bug.
This is reproducible with gcc 2.96-69. According to the maintainers
of wavelan.c and include/asm-i386/delay.h it's a defect in that rev
of gcc where __builtin_constant_p() doesn't work. 2.96-69 is what's
currently on updates.redhat.com for 7.0.
How hard is it to get a newer gcc released as a 7.0 update?