Re: Vmware crashes if compress/misc.c scrolls?

[Zachary Amsden <zach@vmware.com>]

Andi Kleen wrote:
> > In the boot decompressor for the kernel in the image Iouri provided, I
> >     
>
> 32bit or 64bit image?
>
>   
> > As you can plainly see, the call to memcpy (which is redefined in
> > boot/compressed/misc.c) is made using stack calling convention.
> > Unfortunately, the compiler generated the memcpy function itself using
> > regparm(3) convention.  I am guessing this happened because a leftover
> >     
>
> I can't find any here grepping .i files and includes. None of the memcpy
> prototypes in include have a __fastcall
>
> Are you sure this still happens in mainline?
>
> When I look at my scroll it also looks correct:
>
>       c0:       0f af f8                imul   %eax,%edi
>       c3:       01 c0                   add    %eax,%eax
>       c5:       89 c2                   mov    %eax,%edx
>       c7:       01 f2                   add    %esi,%edx
>       c9:       89 45 f0                mov    %eax,0xfffffff0(%ebp)
>       cc:       89 f0                   mov    %esi,%eax
>       ce:       89 f9                   mov    %edi,%ecx
>       d0:       e8 7b ff ff ff          call   50 <memcpy>
>
>
>   
> > Does anyone recall compiler problems (I noticed this VM was booting a
> > 64-bit kernel, 
> >     
>
> Ok 64bit, that was 32bit above. 
>
> Since some time the decompressor is 64bit and 64bit always uses 
> regparms. 64bit Scroll is ok too:
>
>      92:       0f af eb                imul   %ebx,%ebp
>       95:       01 db                   add    %ebx,%ebx
>       97:       48 63 f3                movslq %ebx,%rsi
>       9a:       4c 01 ee                add    %r13,%rsi
>       9d:       89 ea                   mov    %ebp,%edx
>       9f:       e8 9c ff ff ff          callq  40 <memcpy>
>
>
>   
> > but the decompressor was 32-bit code, 
> >     
>
> That must be a old kernel.
>
> Can you people please verify this all still happens with a mainline or
> 2.6.22 kernel? 
>   

It doesn't.

>   
> > so perhaps at some  
> > time the 64-bit makefile or toolchain for Linux had some kind of
> > compiler bug).
> >     
>
> I'm not aware of any such bugs.
>
>   

Me neither, nor do any of my current 32-bit or 64-bit kernels have this 
problem.  I was just wondering if it got fixed deliberately, or if some 
old gcc bug out there could still cause such problems with specific 
toolchains.

I'll look up what version the kernel was; Iouri, can you provide us with 
the binutils / gcc versions used to build your kernel?

Zach
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/