Andi Kleen wrote:

quoted

In the boot decompressor for the kernel in the image Iouri provided, I
    

32bit or 64bit image?

  

quoted

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>


  

quoted

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>


  

quoted

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? 

  

quoted

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.
  

It was 2.6.21.4, so it is fairly recent, but with 32-bit decompress 
stage.  GCC was 4.2.0.

Sounds like a gcc bug, to me.

Zach