Bug 579838 - glibc not compatible with AMD Geode LX
Summary: glibc not compatible with AMD Geode LX
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: binutils
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Nick Clifton
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
: 594660 607186 618592 (view as bug list)
Depends On:
Blocks: F15Alpha, F15AlphaBlocker
TreeView+ depends on / blocked
 
Reported: 2010-04-06 17:28 UTC by Dan Horák
Modified: 2019-07-17 14:13 UTC (History)
27 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-02-16 16:30:33 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
f12kernel-f13userspace-1 (11.93 KB, text/plain)
2010-04-06 17:28 UTC, Dan Horák
no flags Details
f12kernel-f13userspace-2 (11.52 KB, text/plain)
2010-04-06 17:29 UTC, Dan Horák
no flags Details
f13kernel-f13userspace (11.37 KB, text/plain)
2010-04-06 17:29 UTC, Dan Horák
no flags Details
disassembly (19.19 KB, text/plain)
2010-04-07 07:43 UTC, Dan Horák
no flags Details
Disable assembler optimizations (1.25 KB, patch)
2010-06-21 03:58 UTC, Daniel Drake
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Sourceware 6957 0 P2 RESOLVED i386 NOPs must be derived from march not mtune 2020-02-04 23:03:51 UTC

Description Dan Horák 2010-04-06 17:28:18 UTC
F-13 userspace can't be booted in system with AMD Geode LX CPU. Per http://fedoraproject.org/wiki/Features/F12X86Support it is a supported CPU for the x86 Fedora. Because the panic or "Illegal instruction" exception appears so early when userspace binaries should be run leads me to think that something is wrong in libc.

The symptoms are
- when booted F-13 kernel + F-13 initramfs => kernel panic when code from initramfs should be executed
- when booted F-12 kernel + F-12 initramfs => unable to chroot to the F-13 userspace, see the attachments for boot logs in 2 situations - first is with init=/bin/bash on the kernel command line, second is with rdbreak=pre-pivot and manual chroot

Version-Release number of selected component (if applicable):
glibc-2.11.90-16

Comment 1 Dan Horák 2010-04-06 17:28:57 UTC
Created attachment 404757 [details]
f12kernel-f13userspace-1

Comment 2 Dan Horák 2010-04-06 17:29:25 UTC
Created attachment 404758 [details]
f12kernel-f13userspace-2

Comment 3 Dan Horák 2010-04-06 17:29:51 UTC
Created attachment 404759 [details]
f13kernel-f13userspace

Comment 4 Dan Horák 2010-04-07 07:43:40 UTC
Created attachment 404857 [details]
disassembly

I have installed gdb into the initramfs and now I can see the exact place of the crash. The NOPL instruction throws the exception and it's really unknown on the Geode LX per http://support.amd.com/us/Embedded_TechDocs/33234H_LX_databook.pdf.

Buildroot used to build this glibc is http://koji.fedoraproject.org/koji/buildrootinfo?buildrootID=742936 and gcc is gcc-4.4.3-8.fc13.i686.rpm

Comment 5 Jakub Jelinek 2010-04-07 07:48:56 UTC
So the CPU isn't i686 compatible and thus isn't supported.

Comment 6 Dan Horák 2010-04-07 08:41:38 UTC
Ok, then we should write a new release note for F-13 about the changed CPU support.

Just for curiosity, where can I get the definition of i686 architecture? I have "Intel® 64 and IA-32 Architectures Software Developer’s Manual", but how can one find there what's i686 and what was added in later CPUs?

Comment 7 Andreas Schwab 2010-04-07 11:15:39 UTC
That should eventually be fixed in the kernel, see <http://marc.info/?l=linux-kernel&m=126748102722641&w=2>.

Comment 8 Till Maas 2010-06-02 09:50:28 UTC
(In reply to comment #5)
> So the CPU isn't i686 compatible and thus isn't supported.    

I opened a Fesco ticket to clarify which CPUs are supported by Fedora:
https://fedorahosted.org/fesco/ticket/387

Comment 9 Dont Close Unfixed Bugs 2010-06-08 04:26:30 UTC
There is no clarification needed by FESCo.  The release was intended to support the Geode LX -- whether or not it is an "i686" (it isn't).  Nothing in the F13 release specifications says anything about changing the set of supported CPUs from F12, which clearly supported the Geode LX (see Comment 1).

Further investigation in the released Fedora 13 i686 LiveCD reveals that NOPL instructions only occur in binaries produced from glibc, and in a couple of statically linked binaries (/sbin/sln and /sbin/mdadm.static) linked with glibc.

NOPL instructions can be generated by the GNU Assembler for .align commands that occur in executable sections.  GCC can generate .align when optimizing, to align loop starts on cache line boundaries.  Gas only generates NOPL when instructed that the machine architecture supports it.  Apparently, sometime between F12 and F13, either gas's .align support was improved or enbugged, or the arguments to gas when compiling glibc were changed to an inappropriate value that excluded the Geode LX.  

This is not a generic problem with every package in the release -- it's a bug in the build configuration or Makefiles of glibc.  This should be fixable by rebuilding the binary packages derived from glibc.  This won't fix the release CDs and DVDs, but will fix the repos, which is key for the largest affected Fedora customer, OLPC.  However, this problem HAS been reported by other users on other Geode LX hardware; see:

  http://sharkcz.livejournal.com/5708.html

This bug was timely reported, but the report was ignored while there was plenty of time to fix the release.

This bug should be reopened -- but bugzilla.redhat.com does not seem to offer me a user interface with which to do that.

The priority of this bug should be increased, because it causes the release media to fail to boot and fail to install on supported hardware.  For the same reason, it should also be documented in the release notes here:

  http://fedoraproject.org/wiki/Common_F13_bugs#Hardware-related_issues

Comment 10 Daniel Drake 2010-06-08 21:28:40 UTC
It's true that Geode LX is not-quite i686 and we seem to be aware of some other places in which it is lacking (in addition to nopl).

This time around it does appear that the only problematic package we know about is glibc, so I'll focus on that case.

The reason that glibc is the only affected package is because glibc's build system checks if the assembler supports the "-mtune" option, and if so, when building for i686 it passes -mtune=i686.

Normally gcc does not pass -mtune or -march to the assembler (surprised me, too). But glibc explicitly checks if the assembler accepts it, and if so, it passes -Wa,-mtune=i686 to gcc, causing gcc to pass -mtune=i686 to the assembler. (the assembler's -march option remains unused)

Passing -mtune=i686 to the assembler causes nopl to be used. This indicates an assembler bug, because mtune should produce enhanced code for a certain arch without breaking compat, but in this case using nopl instructions *will* break compat. This is http://sourceware.org/bugzilla/show_bug.cgi?id=6957 (looks like the developer wants a test case before continuing, I'll try and come up with one now)

Comment 11 Daniel Drake 2010-06-08 22:26:45 UTC
Alright. Posted some test cases on the upstream bug and already got a response.

Invoking "as -mtune=i686" is effectively equivalent to invoking "as -march=i686 -mtune=i686" (a small behavioural difference when compared to gcc). So it will look to produce optimized code for i686, with the whole of the i686 instruction set at its disposition.

So there is no glibc or assembler bug here. We're asking glibc to build for i686, and glibc is doing a better job than most packages of communicating the target architecture through the whole build chain. (by default the optimization flags do not reach the assembler, but glibc makes this happen)

If we want to fix F13, we have a number of options available:
 - build glibc for target arch i586
 - hack glibc build system to use -Wa,-mtune=i586 (i.e. we ask all parts of the build chain to optimize for i686, except for the assembler which we ask to optimize for i586)
 - hack glibc build system to use -Wa,-mtune=i686 -Wa,-march=i586 (i.e. ask the assembler to optimize for i686, but never going outside of the instruction set supported by i586 processes)
 - hack glibc build system so that we don't ask assembler to do any optimizations (like the rest of the world)


In the FESCO meeting, we decided that we should gain a full understanding of this issue before coming up with a decision (do we hack glibc in F13 to fix this? Do we change target arch for F14? or both? or...?). I think with my analysis we have now gained an understanding.

Comment 12 Dan Horák 2010-06-09 06:32:49 UTC
And there is also the NOPL emulator for kernel, that seems to be simple enough. I would use this (the Geode LX is very close to i686) and do iX86 < i686 as secondary arch where other people would profit too.

Comment 13 Jakub Jelinek 2010-06-09 07:02:29 UTC
The NOPL emulator or letting Geode LX use a secondary i586 (or i486) arch is the only reasonable way to resolve this.  All packages are built with -march=i686, so
even if as -mtune=i686 perhaps shouldn't use automatically i686 insns, -march=i686 certainly should.  gcc should switch to telling as to use i686 optimized code for -march=i686, so all packages will eventually have i686 nops.

Comment 14 Andreas Schwab 2010-06-09 07:54:23 UTC
(In reply to comment #11)
> If we want to fix F13, we have a number of options available:
>  - hack glibc build system to use -Wa,-mtune=i686 -Wa,-march=i586 (i.e. ask the
> assembler to optimize for i686, but never going outside of the instruction set
> supported by i586 processes)

$ echo 'cmove %eax,%edx' | as -32 -march=i586 -mtune=i686
{standard input}: Assembler messages:
{standard input}:1: Error: `cmove' is not supported on `i586'

Comment 15 Dont Close Unfixed Bugs 2010-06-09 17:29:00 UTC
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.

Comment 16 Richard W.M. Jones 2010-06-09 18:50:37 UTC
Comment 15: Well argued.

Another way to look at this is that 32 bit x86 is already a legacy
architecture.  No one who cares about performance should be using
it -- all those power users long switched to x86-64.  If you accept
this argument then what we in Fedora should be doing is not making
much effort to optimize 32 bit legacy systems at all.  Rather, we should
work on broadening support to as many old systems as possible by
compiling for the lowest common denominator (i486 or i586 systems
were probably the oldest ones that would have had enough memory to
run mini Fedora spins).

Comment 17 Dont Close Unfixed Bugs 2010-06-10 00:52:27 UTC
I don't think the 36.3 million people who bought Atom netbooks in 2009 think their system is "legacy" -- nor the 58 million expected to buy in 2010 (estimated May 2010: http://www.abiresearch.com/press/1656-2009+Netbook+Shipments+Pass+Expectations%2C+58+Million+Forecast+for+2010).  All CPU vendors are still selling high and growing volumes of 32-bit-only x86 chips.  Their users do care about performance, though the issue is much more about performance-per-watt than about raw performance.  X86 chips without amd64 support are mostly used either in mobile applications where battery life matters, or in embedded boards with limited heat budgets (or fanless operation).

Given the higher penetration of Linux in netbooks (and OLPCs) than on desktops, there may well be more people running Fedora on x86 than on amd64.  Indeed that's exactly what smolt shows:  http://smolt.fedoraproject.org/static/stats/stats.html, with 69% on x86 and 30% on 64-bit, out of about 203,000 reporting hosts.  (Smolt never runs on 1.5 million Fedora OLPCs that are Geode LX's.  XO-1.5's will replace XO-1 sales this year; they use the Via C7-M ULV processor which is also only 32-bit x86 compatible, and all of them will run Fedora.)

Unfortunately the web and repo stats aren't broken out by architecture:  http://fedoraproject.org/wiki/Statistics .  Perhaps this page can be improved to tell us how many accesses are happening to x86 versus x64 repos?

The overall picture is clear:  32-bit x86 is still the dominant architecture in use in Fedora.  We shouldn't break high volume 32-bit chips in Fedora, nor should we stop optimizing for 32-bit systems.

Comment 18 Andreas Schwab 2010-06-10 09:01:05 UTC
*** Bug 594660 has been marked as a duplicate of this bug. ***

Comment 19 Daniel Drake 2010-06-21 03:58:47 UTC
Created attachment 425520 [details]
Disable assembler optimizations

in the FESCO meeting it was decided to patch glibc for F13. Here is an appropriate patch.

The response for F14+ is not yet clear, but will be continue to be discussed in tuesdays meeting.

https://fedorahosted.org/fesco/ticket/387

Comment 20 Chuck Ebbert 2010-06-23 21:50:23 UTC
*** Bug 607186 has been marked as a duplicate of this bug. ***

Comment 21 John Florian 2010-06-30 19:56:06 UTC
Not to be impatient, but is there an estimate of when we might see a patched glibc for F13 hitting the testing repo?

Comment 22 Fedora Update System 2010-07-06 14:14:26 UTC
glibc-2.12-3 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/glibc-2.12-3

Comment 23 Fedora Update System 2010-07-07 17:51:20 UTC
glibc-2.12-3 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update glibc'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/glibc-2.12-3

Comment 24 Dennis Schafroth 2010-07-08 21:50:34 UTC
(In reply to comment #16)
> Comment 15: Well argued.
> 
> Another way to look at this is that 32 bit x86 is already a legacy
> architecture.  No one who cares about performance should be using
> it -- all those power users long switched to x86-64.  If you accept
> this argument then what we in Fedora should be doing is not making
> much effort to optimize 32 bit legacy systems at all.  Rather, we should
> work on broadening support to as many old systems as possible by
> compiling for the lowest common denominator (i486 or i586 systems
> were probably the oldest ones that would have had enough memory to
> run mini Fedora spins).    

hear, hear. I was proud of Linux in the "old days" when it truely supported old hardware. With my Via C3 and C3-2, I have to look at other solutions, perhaps even NetBSD.

I mean this will still support the Atom netbooks. I really dont think "the up to one percentage" gained by going from i586 to i686 was a good choice. I also have a Atom netbook. 

Doesn't most newer Intel Atoms have the 64 bit extension?

Comment 25 Fran Taylor 2010-07-10 00:11:26 UTC
Soekris 5501 with Geode LX processor boots and runs OK after installing this test build.

Comment 26 Fedora Update System 2010-07-13 07:33:42 UTC
glibc-2.12-3 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 27 Chuck Ebbert 2010-07-27 14:50:37 UTC
*** Bug 618592 has been marked as a duplicate of this bug. ***

Comment 28 Peter Robinson 2010-07-27 14:59:49 UTC
I've just started testing this on my Fit-PC1 which has a geode (I would have tested it sooner but its been packed in boxes moving since March and i've only just recovered it. The initial upgrade of "yum upgrade yum rpm glibc" from F-12 has worked and its currently around 50% of the way through the rest of the yum upgrade for the rest of the distro. I'll be doing further testing over the coming days. Looks good so far.

Comment 29 Glen Gray 2010-07-27 15:02:29 UTC
I can verify that doing a rebuild of the Fedora13 livecd with the livecd-creator results in an image that's bootable on my Via C3-2 hardware.

Comment 30 Quentin Neill 2010-09-03 04:38:02 UTC
FYI the Linux binutils 2.20.51.0.11 release contains a fix that no longer generates the offending NOPs for i686.

2010/08/06 patch
   http://sourceware.org/ml/binutils-cvs/2010-08/msg00057.html
2010/08/11 release
   http://gcc.gnu.org/ml/gcc/2010-08/msg00194.html

Comment 31 frank huang 2010-09-06 01:08:36 UTC
Is there any formal FC13 CD/DVD I can download to install on geode? I need a full installtion that is likely Fedora-13-i386-DVD.iso?

Comment 32 Nick Lowe 2010-09-07 18:41:20 UTC
This should really be revisited.

The basic semantics for choosing the NOP sequence were completely wrong. This has been fixed now.
The NOPL instruction is not supported by all i686 processors, the coded assumption was that they all did. This has been changed by the recent AMD patches linked to by Quentin Neill so that it is not assumed and it's specified as an extension where it is supported.

(NOPL is not standard i686, it was undocumented and has just been de facto supported since the Pentium Pro.)

The benefit of full i686 optimisation, which do have real performance implications, are things like bswap (useful in networking), cmpxchg/xadd (used in atomics) and cmov (useful in compiler generated code).

The correct solution is surely to ensure that when something is compiled for generic i686, NOPL is nowhere to be seen...

Once the AMD patches that fix the bad semantics for NOPL and i686 in binutils (GAS) have been applied, the build of eglibc should be changed to restore i686 optimisation.

The frustrating thing is that broken semantics for i686 have led to absurd patches such as the following being proposed as a workaround:

http://groups.google.com/group/linux.kernel/browse_thread/thread/c1ec68f5498236dc/617726bec31595ed?show_docid=617726bec31595ed

The point that gets missed there is that, abstractly, a NOP is meant to be exactly as it says on the tin, a No Operation.

It's meant to do nothing at all - for a predefined number of clock cycles.
A NOP is commonly used for timing purposes, that completely breaks that contract.

Again, NOPL is not standard i686 - it's an extension supported by the vast, vast majority of i686 class processors. If you're compiling generically for i686, you cannot assume that it is present.

Bad patches like the above to work around broken compilation cause more harm than good, plastering over the real problem.

I've also had a brief look at the kernel.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/x86/Makefile_32.cpu;hb=HEAD

… special cases the GX1 to -march=pentium-mmx and the LX to -march=geode,-march=pentium-mmx.

There is also a special case for the bug in binutils for !CONFIG_X86_P6_NOP where -mtune=generic32 is set.

And what about [x86: do not promote TM3x00/TM5x00 to i686-class] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a7ef94e6889186848573a10c5bdb8271405f44de - that patch is based on the bad assumption that i686 includes NOPL when it does not.

I haven't looked thoroughly, there might be more places!

Cheers,

Nick

Comment 33 Andre Robatino 2011-02-04 07:31:39 UTC
The most recent glibc.i686 build for Rawhide ( http://koji.fedoraproject.org/koji/buildinfo?buildID=215507 ) appears to have reintroduced the NOPL instruction. See http://lists.fedoraproject.org/pipermail/test/2011-February/096805.html .

Comment 34 Peter Robinson 2011-02-04 08:06:02 UTC
Re-opening and adding as a F15 Alpha blocker

Comment 35 Daniel Drake 2011-02-07 14:40:19 UTC
Is there a risk that this new binutils version will spit NOPLs into a whole range of packages, not just glibc?

If so this should ideally be given attention this week, as the F15 rebuild is due.

I had a quick look at the changelog and NEWS files of the newest releases and nothing stood out. I took a look at the patches that fixed this originally against the current code, but I don't have the background knowledge to make any meaningful observations.

Comment 36 Jan Kratochvil 2011-02-07 19:10:54 UTC
There is now:

* Mon Feb  7 2011 Jan Kratochvil <jan.kratochvil> - 2.13.90-2
- Put back the assembler "workaround" - to disable the nopl instruction.

which just reverts:
* Tue Jan 25 2011 Andreas Schwab <schwab> - 2.13.90-1
[...]
- Remove no longer needed assembler workaround

so that nopl/nopw are no longer generated on i686.

Comment 37 Daniel Drake 2011-02-07 21:27:21 UTC
Great. Thanks so much for addressing this at short notice :)

Comment 38 Jan Kratochvil 2011-02-08 19:03:11 UTC
http://sourceware.org/ml/binutils/2011-02/msg00071.html
->
I believe glibc should therefore use -march=something, probably -march=i686.

Comment 39 Adam Williamson 2011-02-11 08:34:00 UTC
Leaving notes on proposed blockers as I won't be at the meeting tomorrow most likely:

This hits "The installer must boot (if appropriate) and run on all primary architectures from default live image, DVD, and boot.iso install media", IMO, so is an Alpha blocker. +1

Comment 40 Dennis Gilmore 2011-02-11 17:41:38 UTC
fixed is in glibc-2.13.90-2

Comment 41 Robyn Bergeron 2011-02-11 19:19:39 UTC
AGREED: 579838 - accepted as Alpha blocker as this impacts all XO's and is already fixed.

Comment 42 Andreas Schwab 2011-02-14 08:06:48 UTC
This is *not* a glibc bug.

Comment 43 Jared Smith 2011-02-14 13:48:21 UTC
(In reply to comment #42)
> This is *not* a glibc bug.

Andreas, can you be more specific?  I'd like to get as many details as possible on this, so we can get it assigned to the proper component.

Comment 44 Nick Lowe 2011-02-14 14:28:45 UTC
(In reply to comment #43)
> (In reply to comment #42)
> > This is *not* a glibc bug.
> 
> Andreas, can you be more specific?  I'd like to get as many details as possible
> on this, so we can get it assigned to the proper component.

glibc should not contain NOPL instructions when compiled with -march=i686 against a recent binutils (GAS) version. A workaround in glibc should not be needed.

Refer to my previous comment.

Cheers,

Nick

Comment 45 James Laska 2011-02-16 15:25:47 UTC
@nickc - Any thoughts on how to proceed.  This is currently listed as a F15Alpha release blocker.  THe Alpha release candidate compose is scheduled for this friday (02-18).  For this bug, we'll need either a workaround, a fix, or proof it does not qualify as an F15Alpha release blocker.  Thanks!

Comment 46 Nick Lowe 2011-02-16 16:12:35 UTC
With the workaround reapplied, it is clearly not a blocker. The fix is merely applied in the wrong place. It is just bandaid, if you like.

The longer term view should be to correct things so that the optimal compilation options are used.

Now that binutils has been fixed, i686 is a sane baseline for a 32-bit build.
In my view, the entire 32-bit build of FC15 should be targeted for i686 with -march=i686 with a fixed version of binutils (GAS) that does not make bad assumption over the presence of NOPL.

As far as compatibility impact of compiling for i686, which need to be understood and digested:

VIA Edens based on the 'Samuel 2' design do not support CMOV or NOPL. (These would break.)
All VIA Edens based on the 'Nehemiah' design support CMOV but not NOPL. (Introduced in 2003. These would not break.)

Via C3s based on the 'Samuel 2'or 'Ezra'/'Ezra-T' design do not support CMOV or NOPL. (These would break.)
All C3s based on the 'Nehemiah' design support CMOV but not NOPL. (Introduced in 2003. These would not break.)

National Semi's GXm, GXLV and GX1 do not support CMOV or NOPL. (These would break.)
All Geodes since and including National Semi's GX2 support CMOV but not NOPL. (Introduced in 2002. These would not break.) 
The AMD branded Geodes (GX and LX) support CMOV but not NOPL. (These would not break.)

The Cyrix 6x86 processors do not support CMOV or NOPL. (These would break.)
The Cyrix 8x86MX / Cyrix MII do support CMOV but not NOPL. (These would not break.)

The AMD K6 and K6-2 do not support CMOV or NOPL. (These would break.)

Comment 47 Adam Williamson 2011-02-16 16:30:33 UTC
This bug is for NOPL instructions existing in glibc. That bug is clearly now fixed, hence this should be closed. Nick, if you think that working around the issue in glibc is the wrong fix, can you please file a new bug against whichever component should be fixed so that glibc does not need to include a workaround (I'm guessing binutils)? It would be easier to track the correct issues that way; we should close this one so it's no longer blocking the Alpha release. Thanks.


Note You need to log in before you can comment on or make changes to this bug.