Re: cvs commit: src/sys/i386/isa apic_vector.s clock.c src/sys/kern kern_intr.c kern_sig.c kern_slaballoc.c kern_switch.c kern_systimer.c kern_upcall.c lwkt_msgport.c lwkt_thread.c lwkt_token.c src/sys/sys slaballoc.h

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:
:On Thu, Feb 19, 2004 at 11:44:05AM -0800, Matthew Dillon wrote:
:> :> Interestingly enough, on my dfly test box, recent kernels built with gcc2
:> :> along with CPUTYPE=i686 set in make.conf yield broken kernels almost
:> :> identical to what you are describing. Removing CPUTYPE from make.conf yields
:> :> working kernel with gcc2. Is this reproducible on your end ?
:> :
:> :Yes, that did it.
:> 
:>     Umm..  you guys realize that setting CPUTYPE will generate specific
:>     instructions for that particular processor?  If you do not actually
:>     have a pentium-pro cpu in your box, using CPUTYPE=i686 is likely to
:>     produce instructions that your cpu does not support. 
:> 
:>     In particular, ppro optimizations will use the CMOV instruction.
:>     Is 'CMOV' in the Features line near the top of your dmesg?   
:> 
:>     Post the first 25 lines of your dmesg output.
:
:Sure.
:
:As already mentioned in another message, if I compile kern_slaballoc.c
:without -march=pentiumpro(by specifying NO_CPU_COPT_FLAGS=yes) and the
:kernel boots OK. I've put the assembly outputs at for those who are
:interested:
:  http://les.ath.cx/DragonFly/kern_slaballoc.c
:  http://les.ath.cx/DragonFly/kern_slaballoc.c.ppro
:
:Regards.

    I think you meant '.s' there.  I'm looking at them... 

    Ok, when I use your kern_slaballoc.s.ppro on my machine, it fails.
    Yahhh!

    I then compiled the code from scratch with -march=pentiumpro and
    compared the disassembly:

    This is what I got:

-kern_slaballoc.o:     file format elf32-i386
+x.o:     file format elf32-i386
 
 Disassembly of section .text:
 
@@ -122,8 +122,7 @@
      194:      8b 5d fc                mov    0xfffffffc(%ebp),%ebx
      197:      89 ec                   mov    %ebp,%esp
      199:      5d                      pop    %ebp
-     19a:      c3                      ret    
-     19b:      90                      nop    
+     19a:      89 f6                   mov    %esi,%esi
 
 0000019c <malloc_uninit>:
      19c:      55                      push   %ebp


    kern_slaballoc.o is my compilation, x.o is what I got when I assembled
    yours.

. stabn 68,0,226,.LM33-malloc_init
. LM33:
        movl %ebx,kmemstatistics
. stabn 68,0,227,.LM34-malloc_init
. LM34:
. LBE3:
. L291:
        movl -4(%ebp),%ebx
        movl %ebp,%esp
        popl %ebp
			<<<<<<<<<<<<<<<<<<<< RET instruction missing
. Lfe2:
                .size            malloc_init,.Lfe2-malloc_init
. stabs "type:r(27,2)",64,0,208,3
. stabs "limsize:r(11,12)",64,0,209,0
. stabn 192,0,0,.LBB3-malloc_init
. stabn 224,0,0,.LBE3-malloc_init
. Lscope1:

    See the problem?  I do... the 'RET' instruction is missing from the
    end of the malloc_init() procedure.

    Your GCC2 is generating broken code.  Very broken code.

    So, how did you compile your last buildworld?  Did you compile it with
    GCC2 or GCC3?  Did you use any special options when compiling it? 
    Because whatever you did is causing your gcc2 to produce bad code.

    My GCC2 generates the 'RET' instruction.  Yours doesn't.  You need to
    rebuild your world without any fancy GCC options and pray that the GCC
    you currently have installed doesn't break itself again when it
    recompiles itself.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>