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?
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
> 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
[email protected] 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
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 >>>>>>>>>>>>
> + 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..
[email protected] said:
> At least make the final printk a panic..
[email protected] 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
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. [email protected]
[email protected] 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
David Woodhouse <[email protected]> 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:[email protected]
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
> 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
[email protected] 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
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
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
[email protected] 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
David Woodhouse <[email protected]> said:
> [email protected] 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:[email protected]
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
[email protected] 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