On Wed, Jan 02, 2002 at 04:12:43PM -0700, Tom Rini wrote:
> >
> > Obviously -ffreestanding isn't, because this problem could crop up pretty
> > much anywhere. The involvement of standard library functions is almost
> > coincidence and so -ffreestanding would only fix the current symptom.
>
> After thinking about this a bit more, why wouldn't this be the fix? The
> problem is that gcc is assuming that this is a 'normal' program (or in
> this case, part of a program) and that it, and that the standard rules
> apply, so it optimizes the strcpy into a memcpy. But in this small bit
> of the kernel, it's not. It's not even using the 'standard library
> functions', but what the kernel provides. This problem can only crop up
> in the time before we finish moving ourself around.
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/
This archive was generated by hypermail 2b29 : Mon Jan 07 2002 - 21:00:19 EST