Can't compile 2.4.3 with agcc

Can't compile 2.4.3 with agcc

[mythos]

Using gcc version pgcc-2.95.3 19991024 (AthlonGCC-0.0.3ex3.1)
I can't compile 2.4.3.I get the follow message:

init/main.o: In function `check_fpu':
init/main.o(.text.init+0x65): undefined reference to
`__buggy_fxsr_alignment'
make: *** [vmlinux] Error 1

Can anyone help me?

Re: Can't compile 2.4.3 with agcc

[Russell King]

On Mon, Apr 23, 2001 at 04:13:47PM +0300, mythos wrote:
> Using gcc version pgcc-2.95.3 19991024 (AthlonGCC-0.0.3ex3.1)
> I can't compile 2.4.3.I get the follow message:
> 
> init/main.o: In function `check_fpu':
> init/main.o(.text.init+0x65): undefined reference to
> `__buggy_fxsr_alignment'
> make: *** [vmlinux] Error 1
> 
> Can anyone help me?

This is a FAQ!  (sorry, but I don't know if it is in a FAQ or not).

IIRC, you can't use pgcc to compile linux kernels.

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Can't compile 2.4.3 with agcc

[Alan Cox]

> Using gcc version pgcc-2.95.3 19991024 (AthlonGCC-0.0.3ex3.1)
> I can't compile 2.4.3.I get the follow message:
> 
> init/main.o: In function `check_fpu':
> init/main.o(.text.init+0x65): undefined reference to
> `__buggy_fxsr_alignment'
> make: *** [vmlinux] Error 1
> 
> Can anyone help me?

Thats either a compiler bug or a funny triggering a compiler bug check

Re: Can't compile 2.4.3 with agcc

[David Woodhouse]

rmk@arm.linux.org.uk said:
> On Mon, Apr 23, 2001 at 04:13:47PM +0300, mythos wrote:
> > init/main.o(.text.init+0x65): undefined reference to `__buggy_fxsr_alignment'

> This is a FAQ!  (sorry, but I don't know if it is in a FAQ or not).
>  IIRC, you can't use pgcc to compile linux kernels.

Then the kernel should say so, rather than giving a cryptic message like 
that, and containing code which isn't actually guaranteed to compile, even 
with a compiler which _does_ align the structure as we want it.

Index: include/asm/bugs.h
===================================================================
RCS file: /inst/cvs/linux/include/asm-i386/bugs.h,v
retrieving revision 1.2.2.16
diff -u -r1.2.2.16 bugs.h
--- include/asm/bugs.h	2001/01/18 13:56:53	1.2.2.16
+++ include/asm/bugs.h	2001/04/23 15:45:28
@@ -80,8 +80,10 @@
 	 * Verify that the FXSAVE/FXRSTOR data will be 16-byte aligned.
 	 */
 	if (offsetof(struct task_struct, thread.i387.fxsave) & 15) {
-		extern void __buggy_fxsr_alignment(void);
-		__buggy_fxsr_alignment();
+		printk(KERN_EMERG "ERROR: FXSAVE data are not 16-byte aligned in task_struct.\n");
+		printk(KERN_EMERG "This is usually caused by a buggy compiler (perhaps pgcc?)\n");
+		printk(KERN_EMERG "Cannot continue.\n");
+		for (;;) ;
 	}
 	if (cpu_has_fxsr) {
 		printk(KERN_INFO "Enabling fast FPU save and restore... ");


--
dwmw2

Re: Can't compile 2.4.3 with agcc

[Ingo Oeser]

On Mon, Apr 23, 2001 at 04:52:53PM +0100, David Woodhouse wrote:
> RCS file: /inst/cvs/linux/include/asm-i386/bugs.h,v
> retrieving revision 1.2.2.16
> diff -u -r1.2.2.16 bugs.h
> --- include/asm/bugs.h	2001/01/18 13:56:53	1.2.2.16
> +++ include/asm/bugs.h	2001/04/23 15:45:28
> @@ -80,8 +80,10 @@
>  	 * Verify that the FXSAVE/FXRSTOR data will be 16-byte aligned.
>  	 */
>  	if (offsetof(struct task_struct, thread.i387.fxsave) & 15) {
> -		extern void __buggy_fxsr_alignment(void);
> -		__buggy_fxsr_alignment();
> +		printk(KERN_EMERG "ERROR: FXSAVE data are not 16-byte aligned in task_struct.\n");
> +		printk(KERN_EMERG "This is usually caused by a buggy compiler (perhaps pgcc?)\n");
> +		printk(KERN_EMERG "Cannot continue.\n");
> +		for (;;) ;
replace this with panic() please. Even machines, which reboot on
panic will reboot over and over again here, which surely someone
will notice ;-)
>  	}
>  	if (cpu_has_fxsr) {
>  		printk(KERN_INFO "Enabling fast FPU save and restore... ");

Regards

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag>
         <<<<<<<<<<<<     been there and had much fun   >>>>>>>>>>>>

Re: Can't compile 2.4.3 with agcc

[Alan Cox]

> +		printk(KERN_EMERG "This is usually caused by a buggy compiler (perhaps pgcc?)\n");
> +		printk(KERN_EMERG "Cannot continue.\n");
> +		for (;;) ;

At least make the final printk a panic..

Re: Can't compile 2.4.3 with agcc

[David Woodhouse]

alan@lxorguk.ukuu.org.uk said:
> At least make the final printk a panic.. 

ingo.oeser@informatik.tu-chemnitz.de said:
> replace this with panic() please.

I considered this, but in the end decided to copy the method from a few 
lines above, which triggers in the case of no FPU and no FPE. I wasn't sure 
if there was a reason why we shouldn't panic() here.

RCS file: /inst/cvs/linux/include/asm-i386/bugs.h,v
retrieving revision 1.2.2.16
diff -u -r1.2.2.16 bugs.h
--- include/asm/bugs.h	2001/01/18 13:56:53	1.2.2.16
+++ include/asm/bugs.h	2001/04/23 20:40:57
@@ -80,8 +80,9 @@
 	 * Verify that the FXSAVE/FXRSTOR data will be 16-byte aligned.
 	 */
 	if (offsetof(struct task_struct, thread.i387.fxsave) & 15) {
-		extern void __buggy_fxsr_alignment(void);
-		__buggy_fxsr_alignment();
+		printk(KERN_EMERG "FXSAVE data are not 16-byte aligned in task_struct.\n");
+		printk(KERN_EMERG "This is usually caused by a buggy compiler (perhaps pgcc?)\n");
+		panic("Cannot continue.");
 	}
 	if (cpu_has_fxsr) {
 		printk(KERN_INFO "Enabling fast FPU save and restore... ");


--
dwmw2

Re: Can't compile 2.4.3 with agcc

[Matan Ziv-Av]

On Mon, 23 Apr 2001, David Woodhouse wrote:

> --- include/asm/bugs.h	2001/01/18 13:56:53	1.2.2.16
> +++ include/asm/bugs.h	2001/04/23 15:45:28
> @@ -80,8 +80,10 @@
>  	 * Verify that the FXSAVE/FXRSTOR data will be 16-byte aligned.
>  	 */
>  	if (offsetof(struct task_struct, thread.i387.fxsave) & 15) {
> -		extern void __buggy_fxsr_alignment(void);
> -		__buggy_fxsr_alignment();
> +		printk(KERN_EMERG "ERROR: FXSAVE data are not 16-byte aligned in task_struct.\n");
> +		printk(KERN_EMERG "This is usually caused by a buggy compiler (perhaps pgcc?)\n");
> +		printk(KERN_EMERG "Cannot continue.\n");
> +		for (;;) ;

This is known at compile time, right?
Would it not be better to replace the printk with #error ? Why do I need
to boot the bad kernel to find out that it does not work, when it is
known when compiling? 



-- 
Matan Ziv-Av.                         matan@svgalib.org

Re: Can't compile 2.4.3 with agcc

[David Woodhouse]

matan@svgalib.org said:
>  This is known at compile time, right? Would it not be better to
> replace the printk with #error ? Why do I need to boot the bad kernel
> to find out that it does not work, when it is known when compiling? 

It's known at compile time, but not at preprocessing time, so it can't be 
done with #error. If you can come up with a way of doing it at compile time 
such that:

 1. It's _guaranteed_ to work when the compiler does align the members 
	of the structure as we desire.
 2. It gives a message sufficiently informative that it prevents further
	such reports getting to l-k.

... then I agree, it would be better to do it at compile time. If not, the 
runtime check is the best we can do.

We really ought to have learned by now that we shouldn't be relying on the 
observed behaviour of this week's compiler in this particular phase of the 
moon.

--
dwmw2

Re: Can't compile 2.4.3 with agcc

[Horst von Brand]

David Woodhouse <dwmw2@infradead.org> said:

[...]

> Then the kernel should say so, rather than giving a cryptic message like 
> that, and containing code which isn't actually guaranteed to compile, even 
> with a compiler which _does_ align the structure as we want it.

Your patch (tries to) transform a compile and link time check into a
runtime check. Not nice.
-- 
Dr. Horst H. von Brand                       mailto:vonbrand@inf.utfsm.cl
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: Can't compile 2.4.3 with agcc

[Andrzej Krzysztofowicz]

> It's known at compile time, but not at preprocessing time, so it can't be 
> done with #error. If you can come up with a way of doing it at compile time 
> such that:
> 
>  1. It's _guaranteed_ to work when the compiler does align the members 
> 	of the structure as we desire.
>  2. It gives a message sufficiently informative that it prevents further
> 	such reports getting to l-k.

So maybe make the original error message more informative ?
Just something like:

-             extern void __buggy_fxsr_alignment(void);
-             __buggy_fxsr_alignment();
+             extern void __BUG__task_struct__data_is_not_properly_alligned__Probably_your_compiler_is_buggy(void);
+             __BUG__task_struct__data_is_not_properly_alligned__Probably_your_compiler_is_buggy();

Andrzej

Re: Can't compile 2.4.3 with agcc

[David Woodhouse]

vonbrand@inf.utfsm.cl said:
>  Your patch (tries to) transform a compile and link time check into a
> runtime check. Not nice.

It transforms a broken and cryptic compile-time check into a correct and
informative runtime check.

If you can provide a correct and informative compile-time check, that would 
be wonderful.

--
dwmw2

Re: Can't compile 2.4.3 with agcc

[David Woodhouse]

On Tue, 24 Apr 2001, Andrzej Krzysztofowicz wrote:

> So maybe make the original error message more informative ?
> Just something like:
>
> -             extern void __buggy_fxsr_alignment(void);
> -             __buggy_fxsr_alignment();
> +             extern void __BUG__task_struct__data_is_not_properly_alligned__Probably_your_compiler_is_buggy(void);
> +             __BUG__task_struct__data_is_not_properly_alligned__Probably_your_compiler_is_buggy();

1. People would probably still report that to l-k instead of reading it.
2. It's still not guaranteed to compile, even with correct compilers.

Maybe you can do a post-processing step - a sanity check which is run
_after_ build. But the runtime check is sufficient. People won't randomly
start compiling kernels for production boxen with silly compilers, then
booting them unattended. And if they do, they deserve the downtime.

I agree that a compile-time check would be kinder, but only if it can be
done properly. Show me one, and I'll be happy.

-- 
dwmw2

Re: Can't compile 2.4.3 with agcc

[Russell King]

On Mon, Apr 23, 2001 at 11:54:10PM +0100, David Woodhouse wrote:
> On Tue, 24 Apr 2001, Andrzej Krzysztofowicz wrote:
> > -             extern void __buggy_fxsr_alignment(void);
> > -             __buggy_fxsr_alignment();
> > +             extern void __BUG__task_struct__data_is_not_properly_alligned__Probably_your_compiler_is_buggy(void);
> > +             __BUG__task_struct__data_is_not_properly_alligned__Probably_your_compiler_is_buggy();
> 
> 1. People would probably still report that to l-k instead of reading it.
> 2. It's still not guaranteed to compile, even with correct compilers.
> 
> Maybe you can do a post-processing step - a sanity check which is run
> _after_ build. But the runtime check is sufficient. People won't randomly
> start compiling kernels for production boxen with silly compilers, then
> booting them unattended. And if they do, they deserve the downtime.

grep '__BUG__' System.map | cut -d\  -f3

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Can't compile 2.4.3 with agcc

[David Woodhouse]

rmk@arm.linux.org.uk said:
>  grep '__BUG__' System.map | cut -d\  -f3

Nice try, but nothing prevents even a correct compiler from including it in 
System.map even though it wouldn't have been called.


--
dwmw2

Re: Can't compile 2.4.3 with agcc

[Horst von Brand]

David Woodhouse <dwmw2@infradead.org> said:
> vonbrand@inf.utfsm.cl said:
> >  Your patch (tries to) transform a compile and link time check into a
> > runtime check. Not nice.

> It transforms a broken and cryptic compile-time check into a correct and
> informative runtime check.

These "broken and cryptic" checks have been done several times now. You
could certainly add a note to this effect to the documentation on building
the kernel.

Building a known broken kernel just for the sake of "better error
reporting" is dead wrong, IMO.
-- 
Dr. Horst H. von Brand                       mailto:vonbrand@inf.utfsm.cl
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: Can't compile 2.4.3 with agcc

[David Woodhouse]

vonbrand@inf.utfsm.cl said:
>  These "broken and cryptic" checks have been done several times now.
> You could certainly add a note to this effect to the documentation on
> building the kernel.

> Building a known broken kernel just for the sake of "better error
> reporting" is dead wrong, IMO.

The fact that the error is reported in a cryptic fashion is a minor issue. 
The important point is that the check itself is broken and not guaranteed 
to work even with good compilers. 

--
dwmw2