Messages in this thread | | | Date | Mon, 27 Sep 2004 13:19:24 +0200 | From | "Jan Beulich" <> | Subject | Re: i386 entry.S problems |
| |
>>> Andi Kleen <ak@muc.de> 27.09.04 12:58:57 >>> >"Jan Beulich" <JBeulich@novell.com> writes: >> >> I don't think so. Otherwise, why would arch/i386/Makefile specifically >> deal with this situation? > >It shouldn't be enabled for 2.95, there are known miscompilations >caused by it there. The i386 Makefile enforces this: > >cflags-$(CONFIG_REGPARM) += $(shell if [ $(GCC_VERSION) -ge 0300 ] ; then echo "-mregparm=3"; fi ;)
But that is exactly what I'm trying to account for: As we appear to all agree, with CONFIG_REGPARM but too old a gcc (which is unknown at configuration time and thus the user can't be prevented from turning this option on), mismatches between assembly and C would result. Thus the need for checking the gcc version in (some) assembly files (of course this implies that for preprocessing assembly files one would not try to use a different gcc than that used for compiling the C stuff).
I do, however, believe that it is an inherent weakness of gcc that it doesn't decorate names of functions employing non-standard parameter passing schemes in some way (i.e. similar to the __stdcall decoration on Windows); with such functionality, it'd be much easier and safer to use mixed schemes.
>However this points to a bug in that when someone sets this >on 2.95 the assembly functions who check for CONFIG_REGPARM >explicitely will be subtly miscompiled. Perhaps having >a #error for this case would be better, although that >would break allyesconfig on prehistoric compilers. Maybe >it needs to be special cased in autoconf.h
Jan - 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/
| |