On Tue, May 05, 2009 at 11:44:43PM +0200, Manuel Bouyer wrote: > On Tue, May 05, 2009 at 09:20:02PM +0000, Andrew Doran wrote: > > > but the test binary from the PR segfaults: > > > truc# kdump |less > > > > > > 34 0 ktrace EMUL "netbsd" > > > 34 0 ktrace RET ktrace 0 > > > 34 0 ktrace CALL execve(0xbf7ffc02,0xbf7feb3c,0xbf7feb44) > > > 34 0 ktrace NAMI "./architextIndex" > > > 34 0 architextIndex EMUL "netbsd" > > > 34 0 architextIndex RET syscall JUSTRETURN > > > 34 0 architextIndex PSIG SIGSEGV SIG_DFL: code=SEGV_ACCERR, > > > addr=0xacb 94, trap=4) > > > 34 0 architextIndex NAMI "architextIndex.core" > > > > > > On Xen CLI(%eax) expands to: > > > movl CPUVAR(VCPU),%eax ; > > > movb $1,EVTCHN_UPCALL_MASK(%eax) > > > > At this point the segment registers won't be set up. And %eax contains the > > syscall number. > > > > > I guess this is a problem. Is there a way to account for this somewhere ? > > > > It is difficult to avoid the LDT/segreg problems without having interrupts > > disabled instantly on entry. > > > > Maybe we could add really ugly logic to compensate for it in trap() since > > oosyscall is the only place where we enter with interupts on (I don't know > > how interrupts/traps are set up on xen currently). > > > > xen isn't as vulnerable to the LDT/segreg problem as native x86 because > > it's not MP and doesn't do kernel preemption. For the time being I guess > > it would suffice to #ifdef the 'cli'. > > That's not enough to make the binary run: even with the cli commented > out the test binary segfaults. > There may be something else wrong, I'll try to look further. > > Any way to use gdb to see what it's doing ? The NetBSD/i386 doesn't want > to load this executable ...
Can you ktrace it? At least we then can see if it's hitting the syscall path.
