Hacking

[unixronin]

Finally, things have progressed from bang-head-on-wall to ... well, progress.

First of all, I've solved PART of the issues with the Mayhem G3 laptop.  I'd previously checked the fans and heatsinks, and they looked fine ... from the outside.  Yesterday, at the suggestion of a friend, I partially disassembled the laptop in order to replace the heatsink themal compound.  (A good call; what was there was mostly gone.  It's now been replaced with a fresh layer of Arctic Alumina.)  And, so long as I had the heatsink assembly out anyway, I disassembled it for a thorough cleaning.

The Mayhem's CPU heatsink is basically a fan-pressurized plenum assembly with fine copper-fin heat exchangers at either end, connected via heat pipes to the CPU.  The inside surfaces of both heat exchangers were totally blocked by a layer of dust so thick and dense that it had formed what amounted to a 1/8" layer of solid felt.  NO WONDER the previous owner had reported that it had begun "crashing" at increasingly-short random intervals; it had no cooling airflow whatsoever, and was going into emergency thermal shutdown to avoid destroying its CPU.

With its heat exchanger cleaned and new thermal compound, the Mayhem is now stable running Windows XP Pro, and has been up for two days without a hiccup; I even stress-tested it playing Halo for about twenty minutes, which was driving it into thermal shutdown within about two minutes prior to the cleanup.  (I will note, however:  If you value your sanity, don't ever try to play Halo — or probably any FPS — with a trackpad.  Just don't.).  So, one problem licked; I know the hardware is sound.  Next, I get to re-tackle the problem of getting it to boot under Linux with ACPI enabled.  (Which may now be a solved problem — it is entirely possible that what was happening was it was getting as far as loading the ACPI code, detecting thermal overtemperature condition, and immediately halting.)  With a 100GB hard disk (well... about 94 real GB), I have it partitioned 45GB and 45GB with a roughly 4GB swap partition, and I'll be leaving the XP installation in place and installing Gentoo dual-boot.

Given this success, I went on to also disassemble the M5309 laptop, which I'd been trying to reinstall for the Dread Pirate Bignum (who has decided to name it Post-Dated Check Loan) until it became unable to successfully compile anything, and replace its heatsink thermal compound as well.  (Which turned out to also be a good call; it was that horrible grey waxy stuff, and very little of it was still between the heatsink and the die.)  I then set out to try a new clean install, which not only exhibited no further problems with failed compilations, but successfully recompiled gcc on the very first try — always a good stresstest of a system.  But it still wouldn't build glibc.

And this was where things REALLY got interesting.

Let me start from the beginning.  Post-Dated Check Loan (Petey or pdcl for short) has a Mobile Athlon XP 2500+ processor (making its CPU actually slightly faster than the CPU in my desktop, though it has only a quarter of the memory and generally lower system throughput).  Here's the contents of /proc/cpuinfo:

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 10
model name      : Mobile AMD Athlon(tm) XP 2500+
stepping        : 0
cpu MHz         : 530.052
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov
                  pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow
bogomips        : 1060.10
clflush size    : 32
cache_alignment : 32
address sizes   : 34 bits physical, 32 bits virtual
power management: ts fid vid

Notice that 'sse' in the flags.  SSE, MMX, and 3DNow are all SIMD instruction sets — 'single instruction, multiple data'.  In other words, they are vector processing instruction sets usually used for graphics rendering tasks.  However, it's also possible to use them for fast (faster than 387 hardware FPU) floating point math. You can tell gcc to use SSE instructions for floating point by using the compiler flag -mfpmath=sse.  And I so set it up in CFLAGS in /etc/make.conf, and had it so set up for as long as I've had Linux on that laptop.

Now, for some reason unknown to me, on the new installation on pdcl, SOMETHING (I still don't know what) had for some reason disabled SSE.  I don't yet know what, or why, and hadn't realized that it was disabled.  It's not a problem; it just results in a compile-time warning from gcc that SSE instructions have been disabled, and 387 floating point instructions will be used instead.  And, of course, floating-point math will as a result be slightly slower.

That's up until you come to try to compile glibc.

You see, glibc absolutely requires — no, not SSE; it requires that C cleanup handling be supported by the compiler.  "What's that got to do with SSE floating point math?", you wonder.  And well might you ask.  The answer is, "Absolutely nothing."  Yet, glibc configuration was failing with an error reporting that C cleanup handling was not supported.  (The cleanup attribute specifies that a particular function is to be called when a variable with automatic function scope goes out of scope during a procedure call.  If you don't know what that means, don't worry about it, you don't need to know.)

Now, this is complete nonsense. gcc has had C cleanup handling for years.  But, you see, this is where the disabled SSE instructions come back to bite us sneakily in the ass.  You see, every time glibc configure compiles a little tiny C conftest program to test whether a particular C or system-library feature is available, it gets a warning that SSE instructions are disabled.  But it's just a warning, which configure doesn't care about, so it ignores the irrelevant warning and goes happily on its way to the next test.

Right up to the point, that is, where it tests for C cleanup handling.

You see, configure tests for the presence of C cleanup handling by attempting to compile this specific little snippet of C:

#include <stdio.h>
void cl (void *a) { }
int main ()
{
   int a __attribute__ ((cleanup (cl)));
   puts ("test");
   return 0;
}

Now, here's where the secret minefield lies.  You see, if C cleanup handling is NOT supported, this piece of code will still compile.  But it'll return a warning that the cleanup attribute is not supported.

But configure ignores warnings.  They're only warnings.  It's not set up to detect them.  So on this particular test, it invokes the -Werror compiler directive to treat all warnings as errors.

Now, this is normally fine, because configure doesn't expect gcc to be emitting any other warnings.  But, we have this disabled-SSE thing going on.  So, the test is run, the code is clean, the cleanup attribute is happily accepted, and all is good, except that gcc emits a warning about SSE.  Which -Werror elevates to an error.  So the compile fails.  And so glibc's configure mistakenly thinks that C cleanup handling isn't supported ... because the test isn't clever enough to detect that the warning it GOT wasn't the warning it was looking for.

Now, there's an obvious workarond for this problem; don't use the -mfpmath=sse compiler flag.  But we know we've got SSE, even though something's disabled it.  So why shouldn't we use it?

Well, it turns out we can tell gcc to re-enable SSE by adding another compiler directive, -msse.  And if we compile that particular little test program using -msse -mfpmath=sse, it compiles just fine without any warnings.

Now, -msse is potentially dangerous, because it will enable generation of SSE instructions by the compiler even if they're not actually supported by the processor.  But in this case, we're only going to be compiling code for this machine, and we already know it supports SSE.  So -msse is safe here.  But if we were compiling code to be run on a machine of unknown-at-compile-time x86 architecture, and we wanted it to be able to use SSE (or SSE2, or 3DNow, or...), we'd have to separately compile test code modules with each of the possible SIMD instruction set flags (-msse, -msse2, -msse3, -m3dnow, -m3dnowext, -mmmx, -mmmxext), and use those test code modules on the destination system to determine which code modules to actually run with.

Now, with that all figured out, Post-Dated Check Loan is happily compiling away, installing a complete clean system from scratch.  So Pirate is going to have her laptop after all in another day or two.  (We should probably buy her a new battery at some point though; the one we got with the laptop is down to 29% of its original 4400mWh capacity.)

Then, assuming I can sort out the processor speed control issue on the Mayhem laptop, I just need to source a screen from it somewhere.  (It requires a Quanta QD15LT01 15.4" WXGA active-matrix TFT LCD.  I can find one for about $60 used and asserted to be in good condition, about $77 for a "100% compatible" knockoff with a high-glare gloss surface, or $95 for the genuine article.  Saving $18 for a knockoff screen that I already know will have a glare problem just doesn't seem like a good idea.  But whichever I buy, it's going to have to wait on budget.)

Comments

[ithildae.livejournal.com]

How many iterations did it take to track down the compile bug?

[unixronin.livejournal.com]

Quite a few, across two different install attempts with two different stage3 tarballs, two different versions of glibc, and both out-of-the-box and recompiled gcc, before I finally noticed the -Werror and realized what was happening.

[ithildae.livejournal.com]

I'm impressed.