Further information...
On 10/22/1999 14:09 -0500, Tim Walberg wrote:
>> Haven't had a chance to dig into these too much yet, but
>> here's a couple problems I had:
>>=09
>> 1) setting CONFIG_X86_FX=3Dy resulted in a link time
>> error (unresolved symbol __buggy_fxsr_alignment from
>> line 85 in include/asm-i386/bugs.h) which looks
>> intentional - why it happened on my system I don't
>> know... Looks like it's code that's intended to
>> be optimized out if certain conditions apply; but
>> it wasn't optimized out on my box (maybe due to
>> the use of pgcc -O6 -Os?).
Compiling with egcs 2.91.66 (from RedHat) makes this one
go away.
<personal opinion>
I think this little code blob is really kinda gross. Not sure
there's a better way to do it, but relying on your optimizer
to remove code that will prevent linking seems to be just asking
for trouble down the road. In this particular case, egcs 2.91
optimizes the code away, but pgcc 2.95 doesn't (although, it
arguably could/should). It's entirely possible that additional
code in the nearby vicinity could change things enough that egcs
may even fail to deal with this in the future...
Basically, this code construct doesn't trigger a link-time error
only if alignment is broken, but triggers a link-time error if
either alignment is broken or the compiler optimizer is "broken".
I think it might be better to find a way to do this using
the preprocessor, but it's not enirely obvious to me at the
moment how one might do that. Alternatively one could provide
a default implementation of __buggy_fxsr_alignment that does
something "reasonable" (oops? panic?), but it would be much
better if this were caught at compile time.
</personal opinion>
From 2.2.13ac1 include/asm-i386/bugs.h [line 74]:
<snip>
/*
* If we got so far we can safely turn on FXSAVE/FXRESTORE,
* but make sure we are 16-byte aligned first.
*/
if (offsetof(struct task_struct, tss.i387.hard.fxsave.fxcwd) & 15) {
/*
* This triggers a link-time error if we manage to
* break alignment somehow.
*/
extern void __buggy_fxsr_alignment(void);
__buggy_fxsr_alignment();
}
</snip>
>>=09
>> 2) after I got the kernel built successfully with
>> CONFIG_X86_CPU_OPTIMIZATIONS=3Dy, trying to rebuild
>> the VMware modules failed - compiles are ok, but
>> the insmod step results in an undefined symbol
>> best_memset - maybe someone forgot to export a
>> symbol somewhere? Could also be a VMWare problem,
>> so I'll pursue that route as well. Problem disappeared
>> when I set CONFIG_X86_CPU_OPTIMIZATIONS=3Dn.
>>=09
Still haven't found anything new with this one...
tw
--=20
+------------------------------+--------------------------+
| Tim Walberg | Phone: 847-782-2472 |
| TERAbridge Technologies Corp | FAX: 847-623-1717 |
| 1375 Tri-State Parkway | twalberg@terabridge.com |
| Gurnee, IL 60031 | 800-SKY-TEL2 PIN 9353299 |
+------------------------------+--------------------------+
--2/5bycvrmDh4d1IB
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: D1BYJWvh0AisHmSVqAk2g+x3woAIlmoJ
iQA/AwUBOBDJPsPlnI9tqyVmEQKn/ACdGxxGmcfJabWPAP1XZpS9R8rH4RIAoN0l
nTeZj3Oh+6ZfO0+0YpGASt+1
=Ihp3
-----END PGP SIGNATURE-----
--2/5bycvrmDh4d1IB--
-
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.tux.org/lkml/