Re: Started moving FAQ to the wiki - please review!

[Nix <nix at esperi dot org dot uk>]

On 27 Apr 2012, Joseph S. Myers uttered the following:
> "How can I compile on my fast ix86 machine a working libc for my slow 
> i386? After installing libc, programs abort with "Illegal Instruction"." - 
> remove, you can't build -march=i386 now at least with NPTL (glibc requires 
> atomics only available on i486 and later).

As an aside, I actually had a glibc-induced illegal instruction error
recently, cross-compiling from an x86-64 system with multilibs for
x86-32 and AMD Geode LX: compiling for the Geode produced rare binaries
which, when transferred to the Geode, threw illegal instruction errors
which gdb showed to be inside glibc functions but not inside libc.so.

This turned out to be due to using a binutils from before 2011-02-08 (so
that it generated long NOPs when -mtune=i686 was used) when compiling
the glibc used on that machine, a glibc from after 2010-04-03 (so that
glibc passed -mtune=i686 to the assembler when generating i686 code).
Since the Geode LX is a 686 clone which doesn't support long NOP, I
ended up with a libc_nonshared.a which contained a very few long NOPs in
the code used to implement atexit(), so binaries compiled against that
libc_nonshared.a which happened to use atexit() would SIGILL on
termination even if glibc was subsequently updated to a version not
afflicted by this bug.

This was made doubly fun by the fact that the great majority of
programs do not use atexit(), so worked perfectly, and that fixing this
required upgrading binutils, then glibc, then the affected programs, so
that the fix propagated from the assembler into libc_nonshared.a and
thus into the affected binaries. I hate static linking, and
unfortunately it is still with us to an extent.

I don't thik any mention of this problem in particular should go in the
FAQ -- it is both arcane and rare and due to a pair of bugs fixed for a
year -- but it might be worthwhile mentioning at least that when this
sort of thing happens, you can find the faulting instruction by running
the failing program under GDB and doing a 'disassemble $pc' after the
failure. That'll get people started figuring out what went wrong, at
least.

-- 
NULL && (void)