On Wed, 2015-05-13 at 16:23 +0200, Aurelien Jarno wrote: > Is Intel planning to release new chips without this bug? >
Intel has already released a later version inside the Curie Module with the issue fixed. (https://www-ssl.intel.com/content/www/us/en/wearables/wearable-soc.html) However on the flip side the X1000 based Galileo Gen 2 is still being made, and getting Debian supported on it would be good. > > > The most obvious way to fix this bug is strip the LOCK prefix from glibc > > on X1000. I have prototyped the following on wheezy. > > Are you sure this prefix is only present in the libc, and not in other > binaries? Good question - I did a binary analysis for Minimal + Dev tools 32bit Debian and it looks like some key system tools have this issue independently of libc - seems to be because they are c++ based tools using boost library locking primitives. So you are correct fixing glibc will doesn't fix the system. > > Not everybody has the optimized version installed at every moment, and > as explained above the default libc might be used at some moment. This > will therefore break existing systems. Ok - so I am correct then stripping i386 of LOCK is a non-option, as it would break existing SMP systems. > > > or > > > > 2. Should we do as I describe above, creating a version of glibc > > specifically with the LOCK prefix removed. > > I would rather not add a new glibc build pass just for the X1000 and as > said above I don't think it would work. agreed > > > Trying to balance complexity (a new glibc target) versus not breaking > > any existing platforms. > > If the problem is really limited to the libc, one solution would be to > use the STT_GNU_IFUNC to provide a different version of the affected > functions. I guess that should then be implemented directly upstream. Interesting, I will take a look at this option. However as I said above, the issue is not limited to libc. > > Alternatively as it triggers a segmentation fault, this could probably > be trapped and emulated in the kernel, just like it's done for the FPU > on some architectures. Unfortunately this is not an option as when the bug does occur it corrupts the register state into an irretrievable state - it can't be caught and fixed in the same manner. I am coming around to the idea that they only way to resolve this issue will be to do a Debian port specifically for the X1000, where the assembler is tweaked to omit the LOCK prefix. Open to any alternative strategy for X1000 support. Ray K
