lkml.org 
[lkml]   [2004]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 14:06    [W:0.025 / U:0.976 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site