Comment 93 for bug 587186

Having somebody else fix the bug in some other software component always "seems to be simple enough". In this case, it isn't; there is serious dissent in the kernel team about whether, and how, to make this "simple" instruction emulation work. Independent of the kernel-architecture disagreement, nobody has yet posted a correct patch for "simply" emulating it in the kernel (the best patch opens security holes by peeking at userspace without appropriate permission checks). And if NOPL is going to become common in every program, as Jakub suggested, the last thing we want is for it to take thousands of cycles because it has to trap into the kernel every time it wants to do a no-op!

Perhaps another way to look at the problem is that gcc and gas do not provide a way to target the instruction set of the Geode LX processor. Fedora definitely wants to target these processors, because they are a significant part of the installed base of Fedora - 1.5 million machines to date. (Here's the Fedora Feature notice for the change in F11 that made i586 support the base: http://fedoraproject.org/wiki/Features/ArchitectureSupport . And here's the F12 change that was supposed to support both the i686 AND the Geode LX while desupporting the i586: http://fedoraproject.org/wiki/Features/F12X86Support )

Yet there are no compiler/gas switches that let the full instruction set of the Geode LX processor be used without also including instructions that the processor doesn't implement. This may be a result of the unfortunate Intel-Corporation orientation of the instruction set (in general they like to ignore their competition). Intel did not document the NOPL instruction for the i686, yet all their 686 processors happened to implement it, so it crept into the tools even though it was not part of the documented spec. But other vendors who merely implemented the spec did not implement it. Here is the 1997 "Intel Architecture Software Developer's Manual: Volume 2: Instruction Set Reference" from the Pentium Pro era, as retrieved by the Internet Archive: http://web.archive.org/web/20070221130324/http://developer.intel.com/design/pentium/manuals/24319101.pdf . It does not document NOPL, only the 1-byte NOP instruction. Contrast this with the current "Intel 64 and IA-32 Architectures Software Developers Manual, Volume 2", which does document long NOP instructions: http://www.intel.com/Assets/PDF/manual/253667.pdf .

So one possible resolution is to keep the "i686" designation for this instruction set, but to remove NOPL from the "i686" instruction set, making the GNU tools match the i686 (Pentium Pro and successors) documentation.

What is the actual performance impact of altering GAS to avoid the use of NOPL on the i686 while aligning in executable sections? Since GAS already knows how to align on every kind of processor (it picks from among four or five different alternative NOP selections already), patching gas's NOP selection on i686 seems to be the least intrusive change that would result in long-term support for both the i686 and the Geode LX.

A more intrusive change would be to define an instruction set "geodelx" and for Fedora to supply -march=geodelx -mtune=atom (rather than -march=i686 -mtune=atom). This would allow the use of long NOPs on -march=i686 (real Intel i686s) while avoiding them in the Fedora distribution.

We (the community) may want to do one thing to patch F13, and another thing in the long term (for F14 and other distros). This is because the F13 issue is confined to a small number of packages and yet kills 1.5M customers. We can afford to recompile the world for F14, but if we decide that that's the only fix possible, F13 is dead on Geodes.