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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux