From: <don...@is...> - 2009-10-07 17:44:44
|
I'd like to build/run on an even older linux version than the one I'm using in the "nightly build" mail thread: uname => 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386 GNU/Linux gcc --version => gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7) Is there any intent that new source be able to build on old OS/gcc/... versions and what are the limits? Perhaps each major release comes with a different range of software versions? Should I just give up or is anyone else at all interested in fixing such problems as the one below? ==== cvs up ./configure --with-module=rawsock build-dir which shows near the end (a pleasant surprise) Configure findings: FFI: yes (user requested: default) readline: yes (user requested: default) libsigsegv: yes ... then cd build-dir make and this ends with gcc -I/tmp/clisp/build-dir/gllib -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -DENABLE_UNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -I. -c package.c ../src/package.d:200:10: directives may not be used inside a macro argument ../src/package.d:199:35: unterminated argument list invoking macro "dotimespL" ../src/package.d: In function `rehash_symtab': ../src/package.d:202: warning: implicit declaration of function `dotimespL' ../src/package.d:202: `oldentry' undeclared (first use in this function) ../src/package.d:202: (Each undeclared identifier is reported only once ../src/package.d:202: for each function it appears in.) ../src/package.d:202: invalid lvalue in assignment ../src/package.d:209: parse error before ')' token ../src/package.d:224: `oldsize' undeclared (first use in this function) ../src/package.d:224: `newsize' undeclared (first use in this function) ../src/package.d:238: `size' undeclared (first use in this function) ../src/package.d: At top level: ../src/package.d:243: parse error before '}' token make: *** [package.o] Error 1 |
From: Vladimir T. <vtz...@gm...> - 2009-10-07 17:58:56
|
On 10/7/09, Don Cohen <don...@is...> wrote: > package.c > ../src/package.d:200:10: directives may not be used inside a macro argument > ../src/package.d:199:35: unterminated argument list invoking macro > "dotimespL" Thanks. It's fixed in the cvs (was non-standard preprecessor usage). Vladimir |
From: <don...@is...> - 2009-10-07 18:09:53
|
Vladimir Tzankov writes: > On 10/7/09, Don Cohen <don...@is...> wrote: > > package.c > > ../src/package.d:200:10: directives may not be used inside a macro argument > > ../src/package.d:199:35: unterminated argument list invoking macro > > "dotimespL" > > Thanks. It's fixed in the cvs (was non-standard preprecessor usage). I'd still like to know the answer to the question about intent of backward compatibility. After cvs up, make clean, make now ends with this gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -DENABLE_UNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -I. -fPIC -Wl,-export-dynamic modules.o readline.o -lreadline -lncurses regexi.o @REGEX_O@ calls.o -lm -lcrypt gettext.o lisp.a -lreadline -lncurses -ldl /usr/local/lib/libavcall.a /usr/local/lib/libcallback.a -L/usr/local/lib -lsigsegv -lc libgnu_cl.a -o lisp.run gcc: @REGEX_O@: No such file or directory ./clisp-link: failed in /tmp/clisp/build-dir/base make: *** [base] Error 1 |
From: Sam S. <sd...@gn...> - 2009-10-07 18:15:43
|
Don Cohen wrote: > I'd like to build/run on an even older linux version than the > one I'm using in the "nightly build" mail thread: > uname => > 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386 GNU/Linux > gcc --version => > gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7) > Is there any intent that new source be able to build on old OS/gcc/... > versions and what are the limits? Perhaps each major release comes > with a different range of software versions? well, we do want to support as many platforms as possible, but our resources are limited and such reports are yours are extremely valuable. > Should I just give up or is anyone else at all interested in fixing > such problems as the one below? we welcome patches too. > ==== > cvs up > ./configure --with-module=rawsock build-dir > which shows near the end (a pleasant surprise) > Configure findings: > FFI: yes (user requested: default) > readline: yes (user requested: default) > libsigsegv: yes > ... > then > cd build-dir > make > and this ends with > gcc -I/tmp/clisp/build-dir/gllib -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -DENABLE_UNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -I. -c package.c > ../src/package.d:200:10: directives may not be used inside a macro argument > ../src/package.d:199:35: unterminated argument list invoking macro "dotimespL" > ../src/package.d: In function `rehash_symtab': > ../src/package.d:202: warning: implicit declaration of function `dotimespL' > ../src/package.d:202: `oldentry' undeclared (first use in this function) > ../src/package.d:202: (Each undeclared identifier is reported only once > ../src/package.d:202: for each function it appears in.) > ../src/package.d:202: invalid lvalue in assignment > ../src/package.d:209: parse error before ')' token > ../src/package.d:224: `oldsize' undeclared (first use in this function) > ../src/package.d:224: `newsize' undeclared (first use in this function) > ../src/package.d:238: `size' undeclared (first use in this function) > ../src/package.d: At top level: > ../src/package.d:243: parse error before '}' token > make: *** [package.o] Error 1 > > please try this: --- package.d.~1.130.~ 2009-09-30 10:50:22.000000000 -0400 +++ package.d 2009-10-07 14:13:10.001050000 -0400 @@ -189,8 +189,8 @@ local maygc object rehash_symtab (object (maybe Conses become free): */ { var gcv_object_t* offset = 0; /* offset = sizeof(gcv_object_t)*index */ - var uintC count; - dotimespC(count,oldsize, { + var uintC count = oldsize; + do { var object oldentry = /* entry with number index in oldtable */ *(gcv_object_t*)(pointerplus(&TheSvector(STACK_2)->data[0], (aint)offset)); @@ -206,7 +206,7 @@ local maygc object rehash_symtab (object oldentry = popSTACK(); /* rest-list */ } while (consp(oldentry)); offset++; - }); + } while (--count); } { /* then process symbols, that sit there collision-free: */ var gcv_object_t* offset = 0; /* offset = sizeof(gcv_object_t)*index */ |
From: Sam S. <sd...@gn...> - 2009-10-07 18:19:14
|
Don Cohen wrote: > Vladimir Tzankov writes: > > On 10/7/09, Don Cohen <don...@is...> wrote: > > > package.c > > > ../src/package.d:200:10: directives may not be used inside a macro argument > > > ../src/package.d:199:35: unterminated argument list invoking macro > > > "dotimespL" > > > > Thanks. It's fixed in the cvs (was non-standard preprecessor usage). > > I'd still like to know the answer to the question about intent of > backward compatibility. > > After cvs up, make clean, make now ends with this > gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -DENABLE_UNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -I. -fPIC -Wl,-export-dynamic modules.o readline.o -lreadline -lncurses regexi.o @REGEX_O@ calls.o -lm -lcrypt gettext.o lisp.a -lreadline -lncurses -ldl /usr/local/lib/libavcall.a /usr/local/lib/libcallback.a -L/usr/local/lib -lsigsegv -lc libgnu_cl.a -o lisp.run > gcc: @REGEX_O@: No such file or directory > ./clisp-link: failed in /tmp/clisp/build-dir/base > make: *** [base] Error 1 there is no @REGEX_O@ in the current cvs head. try "cvs up -A" or a fresh checkout |
From: <don...@is...> - 2009-10-07 19:05:52
|
Sam Steingold writes: > there is no @REGEX_O@ in the current cvs head. > try "cvs up -A" or a fresh checkout cvs up -A; make clean; make ended with the same error fresh checkout worked !! now trying MT ... |
From: Sam S. <sd...@gn...> - 2009-10-07 18:20:27
|
Vladimir Tzankov wrote: > > Thanks. It's fixed in the cvs (was non-standard preprecessor usage). I would prefer a fix which would eliminate macros, not introduce new ones. macros reduce readability and debuggability. replacing dotimes with do/while would simplify the code and enable stepping in gdb. |
From: Vladimir T. <vtz...@gm...> - 2009-10-07 18:48:19
|
On 10/7/09, Sam Steingold <sd...@gn...> wrote: > I would prefer a fix which would eliminate macros, not introduce new ones. > macros reduce readability and debuggability. > replacing dotimes with do/while would simplify the code and enable stepping > in gdb. done. your patch is fine. |
From: <don...@is...> - 2009-10-07 19:10:19
|
fresh checkout worked !! now trying MT ... ./configure --with-threads=POSIX_THREADS --with-module=rawsock build-mt cd build-mt make ... gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -pthread -DENABLE_UNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_FFI -DDYNAMIC_MODULES -I. -Wl,-export-dynamic spvw.o spvwtabf.o spvwtabs.o spvwtabo.o eval.o control.o encoding.o pathname.o stream.o socket.o io.o funarg.o array.o hashtabl.o list.o package.o record.o weak.o sequence.o charstrg.o debug.o error.o misc.o time.o predtype.o symbol.o lisparit.o i18n.o foreign.o unixaux.o zthread.o built.o ari80386.o modules.o -lreadline -lncurses -ldl /usr/local/lib/libavcall.a /usr/local/lib/libcallback.a -L/usr/local/lib -lsigsegv -lc libgnu_cl.a -o lisp.run ./lisp.run -B . -N locale -E UTF-8 -Epathname 1:1 -Emisc 1:1 -norc -m 2MW -lp ../src/ -x '(and (load "../src/init.lisp") (sys::%saveinitmem) (ext::exit)) (ext::exit t)' ./lisp.run: relocation error: ./lisp.run: undefined symbol: _current_thread make: *** [interpreted.mem] Error 127 |
From: Vladimir T. <vtz...@gm...> - 2009-10-08 08:26:47
|
On 10/7/09, Don Cohen <don...@is...> wrote: > fresh checkout worked !! > now trying MT ... > ... > ./lisp.run -B . -N locale -E UTF-8 -Epathname 1:1 -Emisc 1:1 -norc -m 2MW > -lp ../src/ -x '(and (load "../src/init.lisp") (sys::%saveinitmem) > (ext::exit)) (ext::exit t)' > ./lisp.run: relocation error: ./lisp.run: undefined symbol: _current_thread > make: *** [interpreted.mem] Error 127 Looks like there is some problem (probably incompatibility between gcc/linker and loader) with "extern __thread" variables. Until it's clear what's wrong you may use -DUSE_CUSTOM_TLS={1,2,3} to enable alternate thread local storage. Briefly (taken from lispbibl.d): USE_CUSTOM_TLS={1,2,3} 1 - using xthread_key_get/set - slowest one (and probably safest) 2 - using slightly modified version of TLS found in Boehm GC for C/C++. 3 - using full page map of address space (4 MB). Basically it is trade-off between performance/memory usage: {1} - xthread_key_get/set is 200-500% slower then native compiler TLS. {2} is about 50-100% slower than compiler TLS support and uses just 8 KB. {3} is almost as fast as single threaded and compiler TLS but uses 4 MB. On OSX (where __thread is not supported by gcc) I use 3. you can configure with: CFLAGS="-DUSE_CUSTOM_TLS=X" ./configure ... Vladimir |
From: <don...@is...> - 2009-10-08 18:13:56
|
Vladimir Tzankov writes: > > ./lisp.run: relocation error: ./lisp.run: undefined symbol: _current_thread > > make: *** [interpreted.mem] Error 127 > > Looks like there is some problem (probably incompatibility between > gcc/linker and loader) with "extern __thread" variables. Until it's > clear what's wrong you may use -DUSE_CUSTOM_TLS={1,2,3} to enable > alternate thread local storage. Sounds like you have some plan for identifying the problem. Any idea how long that will take? Let me know if I can do anything to help. > Briefly (taken from lispbibl.d): > USE_CUSTOM_TLS={1,2,3} > 1 - using xthread_key_get/set - slowest one (and probably safest) > 2 - using slightly modified version of TLS found in Boehm GC for C/C++. > 3 - using full page map of address space (4 MB). > Basically it is trade-off between performance/memory usage: > {1} - xthread_key_get/set is 200-500% slower then native compiler TLS. > {2} is about 50-100% slower than compiler TLS support and uses just 8 KB. > {3} is almost as fast as single threaded and compiler TLS but uses 4 MB. What exactly is x% slower? xthread_key_get/set sounds like it's reading or writing a -per-thread variable. If so, this should have very little impact on typical lisp code, right? What's the default? So far I've only tried 1. I guess I should try 2 next. > you can configure with: > CFLAGS="-DUSE_CUSTOM_TLS=X" ./configure ... That's very useful, thanks. CFLAGS="-DUSE_CUSTOM_TLS=1" ./configure --with-threads=POSIX_THREADS --with-module=rawsock build-mt-tls1 cd build-mt-tls1 make ends with this: make[1]: Leaving directory `/tmp/clispcvs/clisp/build-mt-tls1/rawsock' rm -rf base MAKE=make CLISP="/tmp/clispcvs/clisp/build-mt-tls1/clisp -K boot -E UTF-8 -Epathname 1:1 -Emisc 1:1 -norc" with_dynamic_modules=no ./clisp-link add boot base i18n syscalls regexp readline || (rm -rf base ; exit 1) At this point, after waiting a while and seeing load going to 0, ps faxww shows this: 29075 pts/1 S 0:00 | \_ make 11036 pts/1 S 0:00 | \_ /bin/sh -c MAKE=make CLISP="/tmp/clispcvs/clisp/build-mt-tls1/clisp -K boot -E UTF-8 -Epathname 1:1 -Emisc 1:1 -norc" with_dynamic_modules=no ./clisp-link add boot base i18n syscalls regexp readline || (rm -rf base ; exit 1) 11037 pts/1 S 0:00 | \_ /bin/sh ./clisp-link add boot base i18n syscalls regexp readline 11039 pts/1 S 0:00 | \_ /tmp/clispcvs/clisp/build-mt-tls1/boot/lisp.run -B /tmp/clispcvs/clisp/build-mt-tls1 -M /tmp/clispcvs/clisp/build-mt-tls1/boot/lispinit.mem -N /tmp/clispcvs/clisp/build-mt-tls1/locale -K boot -E UTF-8 -Epathname 1:1 -Emisc 1:1 -norc --version 11042 pts/1 Z 0:00 | \_ [lisp.run <defunct>] At this point I do ^C, and it appears to finish successfully. Perhaps I should send the transcript? At that point I tried make again and I end up at the same place: MAKE=make CLISP="/tmp/clispcvs/clisp/build-mt-tls1/clisp -K boot -E UTF-8 -Epathname 1:1 -Emisc 1:1 -norc" with_dynamic_modules=no ./clisp-link add boot base i18n syscalls regexp readline || (rm -rf base ; exit 1) with the same ps result. |
From: <don...@is...> - 2009-10-08 18:42:14
|
Vladimir Tzankov writes: > you can configure with: > CFLAGS="-DUSE_CUSTOM_TLS=X" ./configure ... So far I've only tried 1. I guess I should try 2 next. It now occurs to me to wonder whether --with-threads=POSIX_THREADS is correctly modified by -DUSE_CUSTOM_TLS or whether one overrides the other (and if so which). Anyway, here's the result: CFLAGS="-DUSE_CUSTOM_TLS=2" ./configure --with-threads=POSIX_THREADS --with-module=rawsock build-mt-tls2 cd build-mt-tls2 make ... gcc -I/tmp/clispcvs/clisp/build-mt-tls2/gllib -DUSE_CUSTOM_TLS=2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -pthread -DENABLE_UNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_FFI -DDYNAMIC_MODULES -I. -DUSE_CLISP_H=1 -DCOMPILE_STANDALONE clisp-test.c -o clisp-test-clisp In file included from clisp-test.c:3: clisp.h:4461: parse error before "xmutex_t" clisp.h:4461: warning: no semicolon at end of struct or union clisp.h:4461: warning: type defaults to `int' in declaration of `tsd' clisp.h:4461: warning: data definition has no type or storage class clisp.h:4462: parse error before "threads_tls" clisp.h:4462: warning: type defaults to `int' in declaration of `threads_tls' clisp.h:4462: warning: data definition has no type or storage class clisp.h: In function `tsd_getspecific': clisp.h:4468: request for member `cache' in something not a structure or union make: *** [clisp.h] Error 1 Above is in linux 2.4.18-14. Both tls=1 and 2 seem to build successfully on the 2.6.17-1.2142_FC4 machine, the subject of the "Re: nightly build" thread. |
From: Vladimir T. <vtz...@gm...> - 2009-10-08 19:23:36
|
On 10/8/09, Don Cohen <don...@is...> wrote: > Vladimir Tzankov writes: > > Briefly (taken from lispbibl.d): > > USE_CUSTOM_TLS={1,2,3} > > 1 - using xthread_key_get/set - slowest one (and probably safest) > > 2 - using slightly modified version of TLS found in Boehm GC for > C/C++. > > 3 - using full page map of address space (4 MB). > > Basically it is trade-off between performance/memory usage: > > {1} - xthread_key_get/set is 200-500% slower then native compiler > TLS. > > {2} is about 50-100% slower than compiler TLS support and uses just > 8 KB. > > {3} is almost as fast as single threaded and compiler TLS but uses 4 > MB. > What exactly is x% slower? > xthread_key_get/set sounds like it's reading or writing a -per-thread > variable. If so, this should have very little impact on typical lisp > code, right? > What's the default? By default none is defined. On linux/freebsd gcc __thread is used for TLS, on all other platforms build fallbacks to {1}. This has serious impact on performance since every access to "global" variables (lisp stack, mv_space, etc) is via call to xthread_key_get (pthread_getspecific or TlsAlloc on win32). {2} maintains small hash (and cache) table based on stack pointer for faster access. {3} again uses stack pointer and big lookup table for mapping to correct globals. I've observed percentages stated above while running tests and benchmarks - they are just indicative. I prefer {3} since it is fastest of the above but takes 4 MB. > CFLAGS="-DUSE_CUSTOM_TLS=1" ./configure --with-threads=POSIX_THREADS > --with-module=rawsock build-mt-tls1 > cd build-mt-tls1 > make > ends with this: > make[1]: Leaving directory `/tmp/clispcvs/clisp/build-mt-tls1/rawsock' > rm -rf base > MAKE=make CLISP="/tmp/clispcvs/clisp/build-mt-tls1/clisp -K boot -E UTF-8 > -Epathname 1:1 -Emisc 1:1 -norc" with_dynamic_modules=no ./clisp-link add > boot base i18n syscalls regexp readline || (rm -rf base ; exit 1) > ... > 11039 pts/1 S 0:00 | \_ /tmp/clispcvs/clisp/build-mt-tls1/boot/lisp.run -B /tmp/clispcvs/clisp/build-mt-tls1 -M /tmp/clispcvs/clisp/build-mt-tls1/boot/lispinit.mem -N /tmp/clispcvs/clisp/build-mt-tls1/locale -K boot -E UTF-8 -Epathname 1:1 -Emisc 1:1 -norc --version I guess: lisp.run -M lispinit.mem --version | head -n 1 will cause the same. If so - can you attach with gdb to hanged process and paste here the stack trace of its threads (check the pid and in gdb do: attach <pid> info threads (there should be 2 threads) thread XX (from above) - to switch to particular thread where 20) Probably something odd happens when standard output is closed (mishandled SIGPIPE?). |
From: <don...@is...> - 2009-10-09 21:40:04
|
Vladimir Tzankov writes: > USE_CUSTOM_TLS={1,2,3} > {1} - xthread_key_get/set is 200-500% slower then native compiler TLS. > {2} is about 50-100% slower than compiler TLS support and uses just 8 KB. > {3} is almost as fast as single threaded and compiler TLS but uses 4 MB. I had asked what exactly is x% slower. If the code below is representative of "normal lisp code", which I think it is, the answer seems to be that the numbers above represent the total time in running lisp code, not just a few MT related things. As some sample data, I notice that some things in make check call (time ...), so here's the first occurrence of "real time" printed by make check. (TIME-LOOP 100000 5000000000 5000) (:GOOD 100000 NIL) Real time: ... All on the same machine: 20.803516 sec. --with-dynamic-modules=no 57.575115 sec. CFLAGS="-DUSE_CUSTOM_TLS=1" 20.98551 sec. CFLAGS="-DUSE_CUSTOM_TLS=3" |
From: Vladimir T. <vtz...@gm...> - 2009-10-08 19:27:25
|
On 10/8/09, Don Cohen <don...@is...> wrote: > CFLAGS="-DUSE_CUSTOM_TLS=2" ./configure --with-threads=POSIX_THREADS > --with-module=rawsock build-mt-tls2 > cd build-mt-tls2 > make > ... > gcc -I/tmp/clispcvs/clisp/build-mt-tls2/gllib -DUSE_CUSTOM_TLS=2 -W > -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type > -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 > -fexpensive-optimizations -falign-functions=4 -pthread -DENABLE_UNICODE > -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_FFI -DDYNAMIC_MODULES -I. > -DUSE_CLISP_H=1 -DCOMPILE_STANDALONE clisp-test.c -o clisp-test-clisp > In file included from clisp-test.c:3: > clisp.h:4461: parse error before "xmutex_t" > clisp.h:4461: warning: no semicolon at end of struct or union This morning I fixed this in cvs - probably you've not updated on this machine. |
From: <don...@is...> - 2009-10-08 19:57:38
|
Vladimir Tzankov writes: > > clisp.h:4461: parse error before "xmutex_t" > > clisp.h:4461: warning: no semicolon at end of struct or union > > This morning I fixed this in cvs - probably you've not updated on > this machine. cvs up cd build-mt-tls2 make clean [that took longer than I expected] make ... writing test file clisp-test.c wrote 163 tests (155 typedefs, 8 defines) gcc -I/tmp/clispcvs/clisp/build-mt-tls2/gllib -DUSE_CUSTOM_TLS=2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -pthread -DENABLE_UNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_FFI -DDYNAMIC_MODULES -I. -DUSE_CLISP_H=1 -DCOMPILE_STANDALONE clisp-test.c -o clisp-test-clisp In file included from clisp-test.c:3: clisp.h:739: parse error before '*' token clisp.h:4178: parse error before '*' token make: *** [clisp.h] Error 1 |
From: <don...@is...> - 2009-10-08 19:45:50
|
Vladimir Tzankov writes: > By default none is defined. On linux/freebsd gcc __thread is used for which is how fast and uses how much space? > TLS, on all other platforms build fallbacks to {1}. This has serious > impact on performance since every access to "global" variables (lisp > stack, mv_space, etc) is via call to xthread_key_get > (pthread_getspecific or TlsAlloc on win32). This still gives me little idea of cost since I don't know how often these operations are done. I'll try time make check in all three > > 11039 pts/1 S 0:00 | \_ /tmp/clispcvs/clisp/build-mt-tls1/boot/lisp.run -B /tmp/clispcvs/clisp/build-mt-tls1 -M /tmp/clispcvs/clisp/build-mt-tls1/boot/lispinit.mem -N /tmp/clispcvs/clisp/build-mt-tls1/locale -K boot -E UTF-8 -Epathname 1:1 -Emisc 1:1 -norc --version > > I guess: > lisp.run -M lispinit.mem --version | head -n 1 > will cause the same. If so - can you attach with gdb to hanged process > and paste here the stack trace of its threads (check the pid and in > gdb do: > attach <pid> > info threads (there should be 2 threads) > thread XX (from above) - to switch to particular thread > where 20) 4932 pts/1 S 0:00 | \_ boot/lisp.run -M lispinit.mem --version 4934 pts/1 Z 0:00 | \_ [lisp.run <defunct>] $ gdb ... (gdb) attach 4934 Attaching to process 4934 ptrace: Operation not permitted. (gdb) info threads No stack. so I guess you want the other one (gdb) attach 4932 Attaching to process 4932 Reading symbols from /tmp/clispcvs/clisp/build-mt-tls1/lisp.run...done. Reading symbols from /usr/lib/libreadline.so.4...done. Loaded symbols for /usr/lib/libreadline.so.4 Reading symbols from /usr/lib/libncurses.so.5...done. Loaded symbols for /usr/lib/libncurses.so.5 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/i686/libc.so.6...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /lib/i686/libpthread.so.0...done. [New Thread 8192 (LWP 4932)] [New Thread 16385 (LWP 4934)] Error while reading shared library symbols: Can't attach LWP 4934: Operation not permitted Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 0x42028d69 in sigsuspend () from /lib/i686/libc.so.6 (gdb) info threads 2 Thread 16385 (LWP 4934) Couldn't get registers: No such process. (gdb) |
From: Vladimir T. <vtz...@gm...> - 2009-10-08 20:15:09
|
On 10/8/09, Don Cohen <don...@is...> wrote: > Vladimir Tzankov writes: > > TLS, on all other platforms build fallbacks to {1}. This has serious > > impact on performance since every access to "global" variables (lisp > > stack, mv_space, etc) is via call to xthread_key_get > > (pthread_getspecific or TlsAlloc on win32). > This still gives me little idea of cost since I don't know how often > these operations are done. Very frequently (all the time). > 4932 pts/1 S 0:00 | \_ boot/lisp.run -M > lispinit.mem --version > 4934 pts/1 Z 0:00 | \_ [lisp.run <defunct>] What you get for: getconf GNU_LIBPTHREAD_VERSION MT was never tested under linuxthreads (http://en.wikipedia.org/wiki/Linuxthreads) and probably will not run properly under it (SIGUSR1 & SIGUSR2 are used internally by MT and there are subtle differences in signal handling). |
From: <don...@is...> - 2009-10-08 20:28:12
|
> What you get for: > getconf GNU_LIBPTHREAD_VERSION I guess you mean just execute that from a shell, current directory doesn't matter. $ getconf GNU_LIBPTHREAD_VERSION getconf: Unrecognized variable `GNU_LIBPTHREAD_VERSION' whereas the other machine says NPTL 2.3.6 and the newer machine says 2.10.1 > MT was never tested under linuxthreads > (http://en.wikipedia.org/wiki/Linuxthreads) and probably will not run > properly under it (SIGUSR1 & SIGUSR2 are used internally by MT and > there are subtle differences in signal handling). But tls=1/2/3 should (or could) still work? |
From: Vladimir T. <vtz...@gm...> - 2009-10-08 20:50:19
|
On 10/8/09, Don Cohen <don...@is...> wrote: > $ getconf GNU_LIBPTHREAD_VERSION > getconf: Unrecognized variable `GNU_LIBPTHREAD_VERSION' You have linuxthreads. run glibc to verify (/lib/libc.so.6 on my machine and it is executable). > > MT was never tested under linuxthreads > > (http://en.wikipedia.org/wiki/Linuxthreads) and probably will not run > > properly under it (SIGUSR1 & SIGUSR2 are used internally by MT and > > there are subtle differences in signal handling). > > But tls=1/2/3 should (or could) still work? No, these are just for providing thread local storage. |
From: <don...@is...> - 2009-10-08 21:24:09
|
Vladimir Tzankov writes: > On 10/8/09, Don Cohen <don...@is...> wrote: > > $ getconf GNU_LIBPTHREAD_VERSION > > getconf: Unrecognized variable `GNU_LIBPTHREAD_VERSION' > > You have linuxthreads. > run glibc to verify (/lib/libc.so.6 on my machine and it is executable). wow, this never occurred to me $ /lib/libc.so.6 GNU C Library development release version 2.2.93, by Roland McGrath et al. Copyright (C) 1992-2001, 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 3.2 20020903 (Red Hat Linux 8.0 3.2-7). Compiled on a Linux 2.4.9-9 system on 2002-09-05. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others The C stubs add-on version 2.1.2. linuxthreads-0.10 by Xavier Leroy BIND-8.2.3-T5B NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Glibc-2.0 compatibility add-on by Cristian Gafton libthread_db work sponsored by Alpha Processor Inc Report bugs using the `glibcbug' script to <bu...@gn...>. > > > MT was never tested under linuxthreads > > > (http://en.wikipedia.org/wiki/Linuxthreads) and probably will not run > > > properly under it (SIGUSR1 & SIGUSR2 are used internally by MT and > > > there are subtle differences in signal handling). > > > > But tls=1/2/3 should (or could) still work? > > No, these are just for providing thread local storage. So can I install nptl somehow? I recall that installing stuff on old systems is often nontrivial, to say the least. Or is it time to give up? |