Sebastian Herbszt
2009-May-25 20:32 UTC
[syslinux] Crash with core32 (syslinux-3.81-pre12-68-g4a211f6)
I got a qemu crash and errors reported in bochs while trying to get latest core32 branch working (pxelinux): qemu: fatal: Trying to execute code outside RAM or ROM at 0xe6e8aa07 EAX=6e0c7811 EBX=000034b3 ECX=ca68b338 EDX=00000048 ESI=750e3fff EDI=00000020 EBP=d07e4988 ESP=00102324 EIP=e6e8aa07 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0028 00000000 ffffffff 00cf9300 CS =0020 00000000 ffffffff 00cf9b00 SS =0028 00000000 ffffffff 00cf9300 DS =0028 00000000 ffffffff 00cf9300 FS =0000 00000000 00000000 00000000 GS =0000 00000000 00000000 00000000 LDT=0000 00000000 00000000 00008200 TR =0008 00000580 00000067 00008900 GDT= 0000b050 0000002f IDT= 00002800 000007ff CR0=60000011 CR2=00000000 CR3=00000000 CR4=00000000 DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 DR6=ffff0ff0 DR7=00000400 CCS=00000044 CCD=00000000 CCO=EFLAGS FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 bochsout.txt: 00540593725e[CPU0 ] write_virtual_checks(): no write access to seg 00540593814e[CPU0 ] fetch_raw_descriptor: GDT: index (3a27)744 > limit (2f) 00540593903e[CPU0 ] fetch_raw_descriptor: LDTR.valid=0 ... 00540644544e[CPU0 ] fetch_raw_descriptor: LDTR.valid=0 00540644633e[CPU0 ] fetch_raw_descriptor: GDT: index (3137)626 > limit (2f) 00540644666e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff] - Sebastian
H. Peter Anvin
2009-May-25 21:14 UTC
[syslinux] Crash with core32 (syslinux-3.81-pre12-68-g4a211f6)
Sebastian Herbszt wrote:> I got a qemu crash and errors reported in bochs while trying to get > latest core32 > branch working (pxelinux): > > bochsout.txt: > > 00540593725e[CPU0 ] write_virtual_checks(): no write access to seg > 00540593814e[CPU0 ] fetch_raw_descriptor: GDT: index (3a27)744 > limit (2f) > 00540593903e[CPU0 ] fetch_raw_descriptor: LDTR.valid=0 > ... > 00540644544e[CPU0 ] fetch_raw_descriptor: LDTR.valid=0 > 00540644633e[CPU0 ] fetch_raw_descriptor: GDT: index (3137)626 > limit (2f) > 00540644666e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff] >It Works For Me[TM] in KVM... In Bochs, one can often set a simulation time breakpoint with the "sba" command (the number at the front is the simulation time) and execute until a little bit before the failure ... it makes it easier to see. In both cases it looks like it's jumping through an invalid pointer. -hpa P.S. Make sure you have the latest core32 branch... it was seriously broken until my changes this morning. -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
Sebastian Herbszt
2009-May-25 21:54 UTC
[syslinux] Crash with core32 (syslinux-3.81-pre12-68-g4a211f6)
Sebastian Herbszt wrote:> H. Peter Anvin wrote: >> Sebastian Herbszt wrote: >>> I got a qemu crash and errors reported in bochs while trying to get >>> latest core32 >>> branch working (pxelinux): >>> >>> bochsout.txt: >>> >>> 00540593725e[CPU0 ] write_virtual_checks(): no write access to seg >>> 00540593814e[CPU0 ] fetch_raw_descriptor: GDT: index (3a27)744 > limit (2f) >>> 00540593903e[CPU0 ] fetch_raw_descriptor: LDTR.valid=0 >>> ... >>> 00540644544e[CPU0 ] fetch_raw_descriptor: LDTR.valid=0 >>> 00540644633e[CPU0 ] fetch_raw_descriptor: GDT: index (3137)626 > limit (2f) >>> 00540644666e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff] >>> >> >> It Works For Me[TM] in KVM... >> >> In Bochs, one can often set a simulation time breakpoint with the "sba" >> command (the number at the front is the simulation time) and execute >> until a little bit before the failure ... it makes it easier to see. > > It seems to fail while running "hello" (pm_call hello). > > 0x0010016c <myputs+0>: push %ebx > 0x0010016d <myputs+1>: sub $0x8,%esp > 0x00100170 <myputs+4>: mov %eax,%ebx > 0x00100172 <myputs+6>: jmp 0x10017d <myputs+17> > 0x00100174 <myputs+8>: inc %ebx > 0x00100175 <myputs+9>: movsbl %al,%eax > 0x00100178 <myputs+12>: call 0x100130 <myputchar> <- boom > 0x0010017d <myputs+17>: mov (%ebx),%al > 0x0010017f <myputs+19>: test %al,%al > 0x00100181 <myputs+21>: jne 0x100174 <myputs+8> > 0x00100183 <myputs+23>: pop %eax > 0x00100184 <myputs+24>: pop %edx > 0x00100185 <myputs+25>: pop %ebx > 0x00100186 <myputs+26>: ret > > 0x00100130 <myputchar+0>: push %ebx > 0x00100131 <myputchar+1>: sub $0xc,%esp > 0x00100134 <myputchar+4>: mov %eax,%ebx > 0x00100136 <myputchar+6>: movb $0x2,0x1003a5 > 0x0010013d <myputchar+13>: mov %al,0x10039c > 0x00100142 <myputchar+18>: push $0x0 > 0x00100144 <myputchar+20>: push $0x100380 > 0x00100149 <myputchar+25>: push $0x21 > 0x0010014b <myputchar+27>: call 0x10003b <core_intcall> <- boom > 0x00100150 <myputchar+32>: mov 0x10030c,%eax > 0x00100155 <myputchar+37>: lea 0x1f00(%ebx),%edx > 0x0010015b <myputchar+43>: mov %dx,(%eax) > 0x0010015e <myputchar+46>: add $0x2,%eax > 0x00100161 <myputchar+49>: mov %eax,0x10030c > 0x00100166 <myputchar+54>: add $0x18,%esp > 0x00100169 <myputchar+57>: pop %ebx > 0x0010016a <myputchar+58>: ret > > Then it goes thru core_intcall, core_syscall, comboot_int21, > core_syscall.rm_return, enter_pm and jumps to 0x000034b4 > (0020:00000000000034b4) in enter_pm.in_pm by doing "jmp ebx": > > 8783 0000AD0B 8B25[4C040000] <2> mov esp,[PMESP] ; Load protmode %esp > 8784 0000AD11 89E8 <2> mov eax,ebp ; EAX -> top of real-mode stack > 8785 0000AD13 FFE3 <2> jmp ebx ; Go to where we need to go > >> In both cases it looks like it's jumping through an invalid pointer.This is how the stack looks like: <bochs:135> print-stack Stack address size 4 | STACK 0x001023b4 [0x00000000] | STACK 0x001023b8 [0x3feabe00] | STACK 0x001023bc [0x0000bc09] | STACK 0x001023c0 [0x00007ba2] | STACK 0x001023c4 [0x00000048] | STACK 0x001023c8 [0x00000212] | STACK 0x001023cc [0x00100150] | STACK 0x001023d0 [0x00000021] | STACK 0x001023d4 [0x00100380] | STACK 0x001023d8 [0x00000000] | STACK 0x001023dc [0x00003418] | STACK 0x001023e0 [0x00000871] | STACK 0x001023e4 [0x3fea4e98] | STACK 0x001023e8 [0x001002f1] | STACK 0x001023ec [0x0010017d] | STACK 0x001023f0 [0x0000d004] and myputchar() got 0x00100149 <myputchar+25>: push $0x21 0x0010014b <myputchar+27>: call 0x10003b <core_intcall> 0x00100150 <myputchar+32>: mov 0x10030c,%eax so the return address is at STACK 0x001023cc [0x00100150] - Sebastian
H. Peter Anvin
2009-May-26 19:13 UTC
[syslinux] Crash with core32 (syslinux-3.81-pre12-68-g4a211f6)
Sebastian Herbszt wrote:> H. Peter Anvin wrote: >> By the way, watch out for missing dependencies. I just checked in a >> dependency fix. > > Still no go. > core_syscall.rm_return from pxelinux.lst: > > 9237 0000A31F 66BB[94000000] <3> mov ebx,.pm_return > 9238 0000A325 E933FE <3> jmp enter_pm > ... > 9245 <3> .pm_return: > 9246 00100094 670FB736[182C] <3> movzx esi,word [word RealModeSSSP] > > Tracing in bochs gives > > 0000a31f: ( ): mov ebx, 0x000034b4 ; 66bbb4340000 >What does "objdump -dr pxelinux.o" show for that chunk of code? Either nasm or ld is doing something very wrong here, and probably is unsupportable. -hpa
Sebastian Herbszt
2009-May-26 20:14 UTC
[syslinux] Crash with core32 (syslinux-3.81-pre12-68-g4a211f6)
H. Peter Anvin wrote:> Sebastian Herbszt wrote: >> # objdump -dr pxelinux.o > > You may have to explicitly make this file."make pxelinux.o" worked.> As a correction, should have been objdump -m i8086 -dr pxelinux.o.00002710 <core_syscall.rm_return>: 2710: 2e 8b 26 e4 12 mov %cs:0x12e4,%sp 2713: R_386_16 .bss16 2715: 66 9c pushfl 2717: 66 60 pushal 2719: 1e push %ds 271a: 06 push %es 271b: 0f a0 push %fs 271d: 0f a8 push %gs 271f: 66 bb 94 00 00 00 mov $0x94,%ebx 2721: R_386_32 __bss16_start 2725: e9 33 fe jmp 255b <enter_pm> - Sebastian