>> <quote>
>>> A new problem that just has appeared today is that Linux 2.1 uses
>>> __attribute__((regparm)) for some critical functions, and at least egcs 1.0
>>> seems to have problems to generate correct code with this in all cases.
>> Oh god. Please stop them from doing this. regparm does not work on
>> the x86 and will never work correctly on the x86. They're just going
>> to shoot themselves in the foot.
>> </quote>
Hmmm..., well, actually, I'm the guy that put in fastcall support in gcc
in the first place. Would you believe that I had complete kernels and
libc's compiled with regparm=1, regparm=2, regparm=3, regparm=4 *and*
regparm=5. All working flawlessly (that was with Linux kernel 1.0.4).
Actually, regparm support for x86 works just fine, it's just that in
order for it to work correctly in all cases, exactly one patch was/is
missing from gcc (dozens already went in to get it as far as it is today).
This patch did not make it into gcc because it wasn't clean enough.
Also, the problem only cropped up in situations where gcc was extremely
pressed for registers. I.e. it's due to a generic failure in gcc to
deal with extreme situations (which merely have a lower probability of
occurring when you do not use regparm), not due to a generic incapability
to deal with regparm.
>a solution though, probably the best way is to remove FASTCALL completely
>because it apparently does not even work reliably on 2.7.2.
Not 100%, true. Not really a reason to drop it completely I think, since
gcc is fixable. It actually is a rather small fix, I just didn't have
the time and energy anymore to fight with the rest of the gcc-team to
get this last patch in in a way that was acceptable to them.
Mind you, it took me two months to produce a compiler and libc that
worked flawlessly with regparm support up till and including regparm=5.
It then took me 1.7 years to actually get 99% of all needed patches into
gcc.
Maybe this has changed with egcs, and getting patches in has become easier.
I didn't have time to try this out yet.
-- Sincerely, srb@cuci.nl Stephen R. van den Berg (AKA BuGless).Skiing beyond this point may result in death and/or loss of skiing privileges.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html