cvs commit: src/sys/amd64/amd64 support.S

[John Baldwin]

On Tuesday 15 August 2006 09:55, Kostik Belousov wrote:
> On Tue, Aug 15, 2006 at 09:34:46PM +0800, David Xu wrote:
> > On Tuesday 15 August 2006 21:13, John Baldwin wrote:
> > > On Tuesday 15 August 2006 08:45, David Xu wrote:
> > > > davidxu     2006-08-15 12:45:51 UTC
> > > >
> > > >   FreeBSD src repository
> > > >
> > > >   Modified files:
> > > >     sys/amd64/amd64      support.S
> > > >   Log:
> > > >   Because fuword on AMD64 returns 64bit long integer -1 on fault, 
clear
> > > >   entire %rax to zero instead of only clearing %eax, otherwise it will
> > > >   leave garbage data in upper 32 bits.
> > >
> > > Are you sure that 'xorl %eax,%eax' doesn't actually clear all 64 bits? 
> > > This practice of just using xorl rather than xorq is all over the place 
in
> > > the amd64 code, and I think I've even seen gcc generate it, so I'm 
guessing
> > > that the xorl actually is a xorq.
> > 
> > >From my understanding, they are different.
> > 
> > before my change, generated binary code:
> > 
> > 0000000000003ba0 <fusufault>:
> >     3ba0:       65 48 8b 0c 25 20 00    mov    %gs:0x20,%rcx
> >     3ba7:       00 00
> >     3ba9:       31 c0                   xor    %eax,%eax
> >     3bab:       48 89 81 a8 02 00 00    mov    %rax,0x2a8(%rcx)
> >     3bb2:       48 ff c8                dec    %rax
> >     3bb5:       c3                      retq
> >     3bb6:       66                      data16
> >     3bb7:       66                      data16
> >     3bb8:       66                      data16
> > 
> > =======================================
> > after this change:
> > 
> > 0000000000003ba0 <fusufault>:
> >     3ba0:       65 48 8b 0c 25 20 00    mov    %gs:0x20,%rcx
> >     3ba7:       00 00
> >     3ba9:       48 31 c0                xor    %rax,%rax
> >     3bac:       48 89 81 a8 02 00 00    mov    %rax,0x2a8(%rcx)
> >     3bb3:       48 ff c8                dec    %rax
> >     3bb6:       c3                      retq
> > 
> > 
> > I have only checked fuword while I am working on userland mutex
> > priority propagating, I have not checked suword and others yet.
> 
> From the IA32 Software Developer Manual, 3.4.1.1:
> 
> When in 64-bit mode, operand size determines the number of valid bits in
> the destination general-purpose register:
> 
>    64-bit operands generate a 64-bit result in the destination
> general-purpose register.
> 
>    32-bit operands generate a 32-bit result, zero-extended to a 64-bit
> result in the destination general-purpose register.
> 
> So, it seems that xorq %rax, %rax and xorl %eax, %eax will make the
> same results, but in the different ways. And xorq requires REX prefix,
> that shall make the decoding longer.

Ok, thanks!  David, can you revert your change?  I had almost gone through 
earlier and fixed all the places that did this a while back until I realized 
that it must have been intentional.

-- 
John Baldwin