> Hi!
Howdy. >On Sun, 6 May 2012 09:25:11 -0700 (PDT), Thomas Thomas <ricinw...@yahoo.com> >wrote: >> I played around and got it to compile, though how I did so is a nasty hack. >What kind of? I caught the output of make to get the full compile command and added ../libpthread/cancel-cond.o into it manually, and saved it as a shell script. Barry, or someone, rewrote cancel-cond.c from cthreads into a pthreads one. I called it nasty because it doesn't fix the makefile, which would be the clean solution. So, it runs as a translator. Spews out some unexpected debugging info that Barry added, but I can add files, delete files, list directories, etc. I haven't tested it under load, however. Thank you for the link on debugging translators. I tried to start a sub-hurd using it, but for some reason it gets to somewhere in libc while trying to create its first thread and derefs a null pointer. I don't have complete debugging info for where it falls apart. Here's the backtrace: #0 0x080d0366 in _hurd_sigstate_lock () #1 0x0805a570 in __pthread_sigstate () #2 0x080598d8 in __pthread_create_internal () #3 0x08059b67 in pthread_create () #4 0x0805b522 in diskfs_start_disk_pager (upi=0x81e0d48, pager_bucket=0x81e0d58, may_cache=1, notify_on_evict=1, size=268435456, image=0x81c1ec4) at disk-pager.c:60 #5 0x08054036 in create_disk_pager () at pager.c:1203 #6 0x0804826b in main (argc=7, argv=0x3ffe78) at ext2fs.c:186 and the offending instruction is (x/i $pc) => 0x80d0366 <_hurd_sigstate_lock+70>: xchg %eax,0x4(%edx) So, with (x/i $pc-8), I find 0x80d035e <_hurd_sigstate_lock+62>: mov $0x1,%eax This looks to me to be the mutex lock code, though I am not good at x86 assembly, and don't know where the previous instruction could be (but then again, no one can). I want to blame cthreads dependencies in libc, because that is the easy solution. Sorry for all this, I have the desire to prove that I am not Completely Incompetent, Thomas D
