Re: CVS commit: src/sys/arch/i386/i386

[Andrew Doran <ad%NetBSD.org@localhost>]

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.