Re: Bug#738575: pthread: segfault in libpthread on Intel Galileo board
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
Reply to: