I'm not arguing your facts, but the "abnormality" is in the different
workings of memory addresses, not in anything related to the standard
library. What if these functions were named differently but gcc were
able to inline them? AFAICS that might trigger the same problem--no
cstdlib confusion involved.
Conversely, what if these were the real stdlib calls that they seem to
be? Still the same bug. Absence or presence of the standard library
is not essential to the problem, and so -ffreestanding can be a fragile
workaround at best.
The bug just happens to get triggered by a 'builtin' optimization, because
gcc 3.0.3 is a little more aggressive with those. We can't keep the
progress of gcc's optimizer back just for a kernel. Asking for a new
option or #pragma, okay. But weeding out otherwise valid assumptions that
help many inputs but break one? Better to fix the one, even if it does
cost you some speed there.
Oh, and another suggestion: would having RELOC cast the pointer to the
intermediate type "const volatile void *" make gcc drop its assumptions
on that one pointer, and avoid the optimization? It may not be exactly
what the Standard had in mind when it defined "volatile," but then again
the definition was deliberately left vague.
OTOH it may have to be cast away again to make strcpy() work at all, and
so that trick might still break...
Jeroen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/