Re: i386/x86_64 segment register issuses (Re: PATCH: Fix x86 segment register access)

["H. J. Lu" <hjl@lucon.org>]

On Tue, Mar 29, 2005 at 04:30:01PM -0800, Linus Torvalds wrote:
> 
> 
> On Mon, 28 Mar 2005, Andi Kleen wrote:
> >
> > "H. J. Lu" <hjl@lucon.org> writes:
> > > The new assembler will disallow them since those instructions with
> > > memory operand will only use the first 16bits. If the memory operand
> > > is 16bit, you won't see any problems. But if the memory destinatin
> > > is 32bit, the upper 16bits may have random values. The new assembler
> > 
> > Does it really have random values on existing x86 hardware?
> 
> The upper bits are not written at all, so it's not random.
> 
> > If it is a only a "theoretical" problem that does not happen
> > in practice I would advise to not do the change.
> 
> My preference too. The reason we use "movl" is because we really do want 
> the 32-bit versions, since they are faster. It's a conscious choice. In 
> contrast "movw" generates bigger and slower code on all assemblers out 
> there, and "mov" doesn't make it clear which one it is. Is it the slow 
> one, or the fast one? 

"mov" shouldn't generate the 0x66 prefix, at least with the assembler
since binutils 2.14.90.0.4 20030523. The assembler in CVS won't generate
0x66 for "movw" either.

> Now, those versions of gas may be so old that nobody cares, but the
> explicit size still is a GOOD THING. The size DOES MATTER. People who want

Suggesting "mov" instead of "movw" is for the existing assemblers. Or
kernel can check assembler version to decide if "movw" should be used.
I can verify the first Linux assembler which won't generate 0x66 for
"movw".

> the smaller and faster version do not want to just rely on gas
> automatically getting it right, especially since gas has historically been
> very very bad at getting things right.

We are fixing those issues in assembler. If people run into problems
like that with gas, they can report them. They will be fixed.

> 
> What is the advantage of not allowing "movl %ds,mem"? Really? Especially
> since I suspect the kernel is pretty much the only one who does this, and
> the kernel really does do it on purpose. The kernel explicitly wants the
> 32-bit version, knowing that the upper bits are undefined.
> 

Kernel has

	unsigned gsindex;
	asm volatile("movl %%gs,%0" : "=g" (gsindex));
	...
	if (gsindex)
		

It is OK if gcc never generates memory access like

	movl %gs,0x128(%rsp)

Otherwise, the upper bits in gsindex are undefined. The new
assembler will make sure that it won't happen.


H.J.