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

[YONETANI Tomokazu]

On Thu, Feb 19, 2004 at 04:14:13PM -0800, Matthew Dillon wrote:
> 
> :
> :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... 

Oops, I'm sorry. I was boiling water for a cup of coffee when I
typed that.

> .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.

Duh! You're right. I did read the diff myself, but I didn't notice that.

>     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.

CCVER=gcc3 with CPUTYPE=p3. No other 'fancy' flags except for -finline-limit
only when I build the kernel with gcc3. I've done installworld several times
this month, and sets of kernel and modules compiled with gcc2 and gcc3.
I can't remember the exact date on which the source tree was checked out,
but the build logs are dated 20040125, 20040207, 20040211, and 20040214.

>     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.

Actually I had another machine running DragonFly, did a buildworld and
installworld from it via NFS. After that, I could build a working kernel
with gcc2 and -march=pentiumpro.

Thanks.