DragonFly bugs List (threaded) for 2004-02
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
: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
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.
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
19c: 55 push %ebp
kern_slaballoc.o is my compilation, x.o is what I got when I assembled
. stabn 68,0,226,.LM33-malloc_init
. stabn 68,0,227,.LM34-malloc_init
<<<<<<<<<<<<<<<<<<<< RET instruction missing
. 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.
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