[9fans] 9vx - os x fix - Plan9

This is a discussion on [9fans] 9vx - os x fix - Plan9 ; It looks like calling fork() in OS X 10.5 doesn't copy the alternate signal stack information into the child. If you add the -F flag to keep it from forking into the background, Andrey says it works fine. I'll tweak ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: [9fans] 9vx - os x fix

  1. [9fans] 9vx - os x fix

    It looks like calling fork() in OS X 10.5 doesn't
    copy the alternate signal stack information into
    the child. If you add the -F flag to keep it from
    forking into the background, Andrey says it
    works fine.

    I'll tweak the code to work around this later.
    For now, just use -F.

    Russ



  2. Re: [9fans] 9vx - os x fix

    Yep that's working ok. Though I'm losing the ability to send capital
    letters to X11 in general, I'm not sure if that's an artifact of this or
    not.
    Dave

    On Fri, Jun 27, 2008 at 8:31 AM, Russ Cox wrote:

    > It looks like calling fork() in OS X 10.5 doesn't
    > copy the alternate signal stack information into
    > the child. If you add the -F flag to keep it from
    > forking into the background, Andrey says it
    > works fine.
    >
    > I'll tweak the code to work around this later.
    > For now, just use -F.
    >
    > Russ
    >
    >
    >



  3. Re: [9fans] 9vx - os x fix

    I can send capital letters just fine, but I can't chord with the
    option/apple buttons like I'm used to on the native drawterm/acme.
    Need to get the latest changes from acme-sac.osx and write a native
    client, I suppose

    Is it supposed to run at full-load? Both cores are fully utilized and
    9vx.OSX uses 187% of the cpu at all times. dtruss reports that the
    main thread is just sitting there doing "select_nocancel(0x0,0x0,0x0)"
    with timeouts.

    On Fri, Jun 27, 2008 at 9:39 AM, David Leimbach wrote:
    > Yep that's working ok. Though I'm losing the ability to send capital
    > letters to X11 in general, I'm not sure if that's an artifact of this or
    > not.
    > Dave
    >



  4. Re: [9fans] 9vx - os x fix

    On Fri, Jun 27, 2008 at 8:56 AM, andrey mirtchovski
    wrote:
    >
    > Is it supposed to run at full-load? Both cores are fully utilized and
    > 9vx.OSX uses 187% of the cpu at all times. dtruss reports that the
    > main thread is just sitting there doing "select_nocancel(0x0,0x0,0x0)"
    > with timeouts.



    is that hlt() :-)

    ron


  5. Re: [9fans] 9vx - os x fix

    i discovered a macos x nasty a while ago that
    means that if you've forked, then accessing certain
    library calls (anything Carbon?) draws an error.

    the stated reason for doing this is that the library
    doesn't work if the stack has been copied,
    but it's a bit of a bugger if you're just forking
    to put yourself in the background.

    is it possible that you're running up against this?

    BTW when i try to make vx32 (under macos 10.5.3) i get the following:

    % make
    make: vx32-gcc: Command not found
    make: vx32-gcc: Command not found
    gcc -m32 -c -nostdinc -Ilibvxc/include -g -O3 -MD -std=gnu99 -I.
    -m80387 -mfp-ret-in-387 -o libvxc/_exit.o libvxc/_exit.c
    libvxc/_exit.c: In function '_exit':
    libvxc/syscall.h:8: error: can't find a register in class 'BREG' while
    reloading 'asm'
    make: *** [libvxc/_exit.o] Error 1


    admittedly i've only had the briefest peruse through the documentation,
    so i'm probably doing something wrong.

    cheers,
    rog.

    On Fri, Jun 27, 2008 at 4:31 PM, Russ Cox wrote:
    > It looks like calling fork() in OS X 10.5 doesn't
    > copy the alternate signal stack information into
    > the child. If you add the -F flag to keep it from
    > forking into the background, Andrey says it
    > works fine.
    >
    > I'll tweak the code to work around this later.
    > For now, just use -F.
    >
    > Russ
    >
    >
    >



  6. Re: [9fans] 9vx - os x fix

    Funny! Chording works great for me! (I'm suspecting my X11 is borked
    though, it may be completely unrelated to this project).

    On Fri, Jun 27, 2008 at 8:56 AM, andrey mirtchovski
    wrote:

    > I can send capital letters just fine, but I can't chord with the
    > option/apple buttons like I'm used to on the native drawterm/acme.
    > Need to get the latest changes from acme-sac.osx and write a native
    > client, I suppose
    >
    > Is it supposed to run at full-load? Both cores are fully utilized and
    > 9vx.OSX uses 187% of the cpu at all times. dtruss reports that the
    > main thread is just sitting there doing "select_nocancel(0x0,0x0,0x0)"
    > with timeouts.
    >
    > On Fri, Jun 27, 2008 at 9:39 AM, David Leimbach wrote:
    > > Yep that's working ok. Though I'm losing the ability to send capital
    > > letters to X11 in general, I'm not sure if that's an artifact of this or
    > > not.
    > > Dave
    > >

    >
    >



  7. Re: [9fans] 9vx - os x fix

    On Fri, Jun 27, 2008 at 10:34 AM, David Leimbach wrote:
    > Funny! Chording works great for me! (I'm suspecting my X11 is borked
    > though, it may be completely unrelated to this project).


    button 2/3 emulation with option and apple keys works, but i'm using
    button1+option+apple to snarf/paste very often, that is the one that
    is not working for me (naturally it works with a 3-button mouse).


  8. Re: [9fans] 9vx - os x fix

    trying to answer my own question about high cpu load, it looks like
    9vx is busy switching all the time. if anyone knows these tracing
    facilities better, please step up

    dappprof (profiles execution, elapsed time is in nanoseconds):

    CALL ELAPSED
    libSystem.B.dylib swtch_pri 67472182
    libSystem.B.dylib sched_yield 75788623
    9vx.OSX unlock 297823144
    9vx.OSX lock 362717059
    9vx.OSX canlock 516405744
    libSystem.B.dylib pthread_getspecific 42273900861098
    9vx.OSX getmach 46118238370761
    libSystem.B.dylib pthread_cond_wait 65330580967450
    libSystem.B.dylib _pthread_cond_wait 222897259712785
    9vx.OSX __i686.get_pc_thunk.bx 1256657382372551

    dapptrace (traces execution, only a small fragment is listed, without
    thread ids):

    -> libSystem.B.dylib:sched_yield(0xF30E0, 0xF30E0, 0xB038CE88)
    -> libSystem.B.dylib:swtch_pri(0x0, 0x0, 0x0)
    -> libSystem.B.dylib:_sysenter_trap(0x93846BC1, 0x0, 0x0)
    <- libSystem.B.dylib:swtch_pri = 10
    <- libSystem.B.dylib:sched_yield = 21
    -> 9vx.OSX:canlock(0xF30E0, 0xF30E0, 0xB038CE88)
    -> 9vx.OSX:__i686.get_pc_thunk.bx(0x0, 0x0, 0x0)
    <- 9vx.OSX:__i686.get_pc_thunk.bx = 3
    -> 9vx.OSX:getmach(0x0, 0x0, 0x0)
    -> 9vx.OSX:__i686.get_pc_thunk.bx(0x101, 0x0, 0x0)
    <- 9vx.OSX:__i686.get_pc_thunk.bx = 3
    -> libSystem.B.dylibthread_getspecific(0x101, 0x0, 0x0)
    <- libSystem.B.dylibthread_getspecific = 12
    <- 9vx.OSX:getmach = 31
    -> 9vx.OSX:getmach(0x0, 0x0, 0x0)
    -> 9vx.OSX:__i686.get_pc_thunk.bx(0x101, 0x0, 0x0)
    <- 9vx.OSX:__i686.get_pc_thunk.bx = 3
    -> libSystem.B.dylibthread_getspecific(0x101, 0x0, 0x0)
    <- libSystem.B.dylibthread_getspecific = 12
    <- 9vx.OSX:getmach = 31
    <- 9vx.OSX:canlock = 104
    -> libSystem.B.dylib:sched_yield(0xF30E0, 0xF30E0, 0xB038CE88)
    -> libSystem.B.dylib:swtch_pri(0x0, 0x0, 0x0)
    -> libSystem.B.dylib:_sysenter_trap(0x93846BC1, 0x0, 0x0)
    <- libSystem.B.dylib:swtch_pri = 10
    <- libSystem.B.dylib:sched_yield = 21

    a gdb backtrace:

    (gdb) attach 25798
    Attaching to process 25798.
    Reading symbols for shared libraries . done
    Reading symbols for shared libraries ....... done
    0x9380a390 in _pthread_cond_wait ()
    (gdb) bt
    #0 0x9380a390 in _pthread_cond_wait ()
    #1 0x93850371 in pthread_cond_wait ()
    #2 0x0000abc6 in idlehands () at 9vx/sched.c:47
    #3 0x000419cd in _runproc () at 9vx/a/proc.c:542
    #4 0x00043696 in sched () at 9vx/a/proc.c:165
    #5 0x00009e48 in main (argc=2, argv=0xbffff6ac) at 9vx/main.c:178
    (gdb) info thread
    Thread 0x10b (local 0xf03) has current state "WAITING"
    Thread 0x10b has a suspend count of 0.
    (gdb) info threads
    9 process 25798 thread 0x1803 0x937d858a in swtch_pri ()
    8 process 25798 thread 0x1703 0x937d858a in swtch_pri ()
    7 process 25798 thread 0x1603 canlock (l=0xf30e0) at 9vx/stub.c:300
    6 process 25798 thread 0x1503 0x937d858a in swtch_pri ()
    5 process 25798 thread 0x1403 0x937d858a in swtch_pri ()
    4 process 25798 thread 0x1103 0x937d858a in swtch_pri ()
    3 process 25798 thread 0x1003 0x9384e24a in __sigwait ()
    2 process 25798 thread 0xf03 0x9383fbf6 in poll$UNIX2003 ()
    * 1 process 25798 thread 0x10b 0x9380a390 in _pthread_cond_wait ()
    (gdb)

    and an sc_usage run (sc_usage traces system calls, i'm including it
    here because it lists what the different threads are doing,
    unfortunately you need to see it run interactively to get an idea of
    what's happening):

    TYPE NUMBER CPU_TIME WAIT_TIME
    ------------------------------------------------------------------------------
    System Idle 0:00.000
    System Busy 0:11.684( 0:00.613)
    9vx.OSX Usermode 0:16.647

    swtch_pri 72985(5840) 0:00.165 1:25.690( 0:05.028) 4
    select_nocancel 70(1) 0:00.000 0:00.844( 0:00.014)


    CURRENT_TYPE LAST_PATHNAME_WAITED_FOR CUR_WAIT_TIME THRD# PRI
    ------------------------------------------------------------------------------
    swtch_pri 0:00.011 0 0
    swtch_pri 0:00.011 1 0
    Pre-empted 0:00.001 2 0
    Running U 0:00.001 3 30
    swtch_pri 0:00.011 4 0
    swtch_pri 0:00.011 5 0


  9. Re: [9fans] 9vx - os x fix

    Replying to many messages... please read to find yours.

    > Yep that's working ok. Though I'm losing the ability to send capital
    > letters to X11 in general, I'm not sure if that's an artifact of this or
    > not.


    Almost certainly not. The -F workaround is about new fork
    semantics. The capital letters thing may be that I missed an
    OS X-specific fix in the X code, imported from p9p.
    I hope someone will take it upon themselves to hook the
    drawterm Carbon code in instead.

    > Is it supposed to run at full-load? Both cores are fully utilized and
    > 9vx.OSX uses 187% of the cpu at all times. dtruss reports that the
    > main thread is just sitting there doing "select_nocancel(0x0,0x0,0x0)"
    > with timeouts.


    I think I mentioned this in an earlier message.
    I don't know what's going on. I hope someone
    else will figure it out. It doesn't do this on Linux
    or FreeBSD, which suggests that perhaps there
    is a bug in the OS X pthreads implementation
    (or in 9vx's use of pthreads). It does make it
    somewhat unbearable.

    > BTW when i try to make vx32 (under macos 10.5.3) i get the following:
    >
    > % make
    > make: vx32-gcc: Command not found
    > make: vx32-gcc: Command not found
    > gcc -m32 -c -nostdinc -Ilibvxc/include -g -O3 -MD -std=gnu99 -I.
    > -m80387 -mfp-ret-in-387 -o libvxc/_exit.o libvxc/_exit.c
    > libvxc/_exit.c: In function '_exit':
    > libvxc/syscall.h:8: error: can't find a register in class 'BREG' while
    > reloading 'asm'
    > make: *** [libvxc/_exit.o] Error 1


    The tree has more than just 9vx.
    To build guests for the other apps you need
    the vx32-gcc cross-compilers to make
    loadable ELF binaries. If you

    make 9vx/9vx

    you'll still get the two "Command not found"
    messages, but they're harmless, and the build
    should run fine.

    > [rminnich@amd64 src]$ make 9vx/9vx
    > make: vx32-gcc: Command not found
    > make: vx32-gcc: Command not found
    > make: *** No rule to make target `9vx/9vx'. Stop.
    >
    > OK, I can see that 9vx/9vx target in 9vx/Makefrag, but the alarm just
    > went off and I gotta go pretend to work. More later. It would be nice
    > to have this work on x86 64 :-)


    Use

    make ARCH=i386

    to override the result of uname -m.
    The 9vx Makefrag knows not to even bother
    trying on x86-64.

    > trying to answer my own question about high cpu load, it looks like
    > 9vx is busy switching all the time. if anyone knows these tracing
    > facilities better, please step up


    You need to figure out which kproc is the one
    that is spinning so hard. The fact that cpu is >100%
    suggests that more than one thread is spinning hard,
    meaning it is is probably not the single-use guys
    like the x11 kproc or the timer kproc. That leaves
    all the kprocs that are waiting on i/o.

    Try adding some iprints to sched.c after each
    call to psleep(), and I bet you'll find an
    insomniac.

    Russ



  10. Re: [9fans] 9vx - os x fix

    > make 9vx/9vx

    on 10.5.3 that fails with:

    gcc -g -O3 -MD -std=gnu99 -I. -I. -I9vx -I9vx/a -Wall
    -Wno-missing-braces -c -o 9vx/main.o 9vx/main.c
    9vx/main.c: In function 'sigsegv':
    9vx/main.c:491: error: 'struct __darwin_mcontext32' has no member named 'es'
    9vx/main.c:492: error: 'struct __darwin_mcontext32' has no member named 'ss'
    9vx/main.c:493: error: 'struct __darwin_mcontext32' has no member named 'ss'
    make: *** [9vx/main.o] Error 1

    turns out that osx exposes __es and __ss for mcontext in
    /usr/include/mach/i386/_structs.h. this fixes it:

    gcc -D__DARWIN_UNIX03=0 -g -O3 -MD -std=gnu99 -I. -I. -I9vx -I9vx/a
    -Wall -Wno-missing-braces -c -o 9vx/main.o 9vx/main.c

    a bit later on:

    gcc -Ilibvx32 -c -g -O3 -MD -std=gnu99 -I. -o libvx32/emu.o libvx32/emu.c
    libvx32/emu.c: In function 'vxproc_run':
    libvx32/emu.c:1796: error: storage size of 'env' isn't known
    make: *** [libvx32/emu.o] Error 1

    is fixed identically by:

    gcc -D__DARWIN_UNIX03=0 -Ilibvx32 -c -g -O3 -MD -std=gnu99 -I. -o
    libvx32/emu.o libvx32/emu.c

    and then later on we fail with:

    gcc -g -O3 -MD -std=gnu99 -I. -I. -I9vx -I9vx/a -Wall
    -Wno-missing-braces -c -o 9vx/stub.o 9vx/stub.c
    make: *** No rule to make target `libvx32/darwin-asm.o', needed by
    `libvx32/libvx32.a'. Stop.

    and darwin-asm.S just seems to be missing everywhere. in fact, there
    is no definition for vx32_getcontext:

    $ find . -type f | xargs grep vx32_getcontext
    ../libvx32/emu.c: if(vx32_getcontext(&env)){
    Binary file ./libvx32/emu.o matches
    ../libvx32/vx32impl.h:int vx32_getcontext(struct i386_thread_state*);
    $


  11. Re: [9fans] 9vx - os x fix

    On Fri, Jun 27, 2008 at 10:00 AM, Russ Cox wrote:

    > Replying to many messages... please read to find yours.
    >
    > > Yep that's working ok. Though I'm losing the ability to send capital
    > > letters to X11 in general, I'm not sure if that's an artifact of this or
    > > not.

    >
    > Almost certainly not. The -F workaround is about new fork
    > semantics. The capital letters thing may be that I missed an
    > OS X-specific fix in the X code, imported from p9p.
    > I hope someone will take it upon themselves to hook the
    > drawterm Carbon code in instead.



    I think there's a high chance Carbon will be "effectively dead" in 6 months
    time. Snow Leopard looms. (10.6), Carbon may still exist, but I wouldn't
    want to bet any future reliance on it.

    It's probably time for a new Cocoa variant of this stuff.

    Then again, I have to wonder about Snow Leopard and *any* 32bit
    applications... I didn't go to WWDC and even if I did, I probably couldn't
    share that information thanks to Apple's openness.

    Dave


  12. Re: [9fans] 9vx - os x fix

    Thanks. Will add the #define.

    > and darwin-asm.S just seems to be missing everywhere. in fact, there
    > is no definition for vx32_getcontext:


    Oops. That's on my Mac at home;
    guess I forgot to copy it off.

    Russ



+ Reply to Thread