[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sys/arch/i386/i386
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
Main Index |
Thread Index |