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 ...
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
