sawfish/librep/gtk + dlopen() and recursive locks.

[Arkadi E. Shishlov]

  Hi.

  I'm trying to compile sawfish wm. librep and libgmp already compiled.
  I've performed basic tests like evaluating expressions, using large
  integers, load(), open() - it seems to work.

  Now I'm trying to compile rep-gtk and I'm in stuck with GTK module
  dynamic loading. After entering ",load gtk" in rep command line it
  spins forever. Closer examinations with GDB show an endless loop
  in __spin_lock_solid().

user> ,load gtk
^C
Program received signal SIGINT, Interrupt.
0x1433c in __swtch_pri () from /lib/ld.so
(gdb) bt
#0  0x1433c in __swtch_pri () from /lib/ld.so
#1  0x1431f in __spin_lock_solid (lock=0x20728) at spin-solid.c:27
#2  0x1246b in __mutex_lock_solid (lock=0x20728) at mutex-solid.c:31
#3  0x980d in add_dependency (undef_map=0x80756d8, map=0x8077940)
    at ../mach/lock-intern.h:77
...

  Full typescript is in attachment.

  Now a bunch of questions. Sorry, somewhat hairy.


  I've found following comment in libc/mach/mutex-solid.c

/* If cthreads is linked in, it will define these functions itself to do
   real cthreads mutex locks.  This file will only be linked in when
   cthreads is not used, and mutexes' are in fact just spin locks (and
   some unused storage).  */

void
__mutex_lock_solid (void *lock)
...

  Does it mean, that Hurd libthreads must be linked in, by supplying
  explicit -l in gcc command line, for dynamic loading to work
  correctly?
  Why there are two implementations of locking primitives?

  Loading other librep modules doesn't trigger such behavior...(?)

  I'm not familar with ELF and other clever linker stuff, so what
  exactly should be linked against libthreads? librep itself,
  librep.so, or librep gtk module? I think, linking librep is enough.

  Also what about recursive mutexes? In libc/elf/dl-open.c:

/* During the program run we must not modify the global data of
   loaded shared object simultanously in two threads.  Therefore we
   protect _dl_open' and _dl_close' in dl-close.c.
      
   This must be a recursive lock since the initializer function of
   the loaded object might as well require a call to this function.
   At this time it is not anymore a problem to modify the tables.  */
__libc_lock_define (extern, _dl_load_lock)

  libc/sysdeps/mach/bits/libc-lock.h:
                 
/* XXX until cthreads supports recursive locks */
#define __libc_lock_define_initialized_recursive __libc_lock_define_initialized

  hurd/libthreads/* seems not to contain special logic for recursive
  locks.

  But libc/elf/dl-open.c:_dl_open() grab _dl_load_lock first and the
  same do libc/elf/dl-lookup.c:add_dependency() later.
  ?

  If it matters, I'm compiling on Linux with cross-compiler. Waiting
  for packages with native compiler...

  Pretend you doesn't see "linux" in rep pathnames and banner -
  cross-compiling librep is just ugly hack.
  

arkadi.
-- 
Today my crystal ball isn't clear
enough to tell you truth.

hurd-librep-gtk-spin
Description: Text document