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

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

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