[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
sawfish/librep/gtk + dlopen() and recursive locks.
From: |
Arkadi E. Shishlov |
Subject: |
sawfish/librep/gtk + dlopen() and recursive locks. |
Date: |
Sun, 11 Mar 2001 02:23:26 +0200 |
User-agent: |
Mutt/1.2.5i |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- sawfish/librep/gtk + dlopen() and recursive locks.,
Arkadi E. Shishlov <=