Re: Support for Intel X1000

["dalias at libc dot org" <dalias at libc dot org>]

On Wed, May 13, 2015 at 10:45:37AM +0000, Kinsella, Ray wrote:
> On Tue, 2015-05-12 at 15:22 +0000, Rich Felker wrote:
> > On Tue, May 12, 2015 at 04:38:04PM +0200, Florian Weimer wrote:
> > > On 05/12/2015 12:28 PM, Kinsella, Ray wrote:
> > > 
> > Not only that, but the code would not be working. In the kernel,
> > defining UP and disabling lock prefix is sufficient because the kernel
> > controls scheduling and interrupt masking and therefore doesn't need
> > atomics except for synchronizing with other physical cores. 
> > 
> The X1000 with the bug is only available in a UP configuration (single
> core, single socket), so there is no other physical cores to synchronize
> with. Granted a glibc build targeting a UP environment like this, would
> immediately break on a multi-core/socket system.

I think it's rather dangerous to produce such binaries -- someone
might compile on such a hacked distro and move the binary to a
different system, unaware of the issues. If anyone is seriously
considering this approach, I think there needs to be some way of
tagging the binaries (e.g. using a different e_machine in the ELF
header, or some other mechanism that will already forcibly break on
existing x86 Linux systems) to make sure this can't happen.

Also, since it's not just glibc you would have to hack the lock prefix
out of, but also all code generated by GCC or other compilers and any
hand-written asm, it would make a lot more sense to put the hack that
NOPs out the lock prefix into the assembler. Then you can just build
all programs with the hacked binutils and get working binaries.

Rich