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
qhwt+dragonfly-bugs at les.ath.cx
Fri Feb 20 06:30:24 PST 2004
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.
> :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
> : http://les.ath.cx/DragonFly/kern_slaballoc.c
> : http://les.ath.cx/DragonFly/kern_slaballoc.c.ppro
> 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
> .stabn 68,0,226,.LM33-malloc_init
> movl %ebx,kmemstatistics
> .stabn 68,0,227,.LM34-malloc_init
> movl -4(%ebp),%ebx
> movl %ebp,%esp
> popl %ebp
> <<<<<<<<<<<<<<<<<<<< RET instruction missing
> .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
> 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.
More information about the Bugs