[Openmcl-devel] 3 questions - TLS the default? global thread-shared vars? .CDB gen broken?
Jason E. Aten
j.e.aten at gmail.com
Sun Mar 20 04:51:49 PDT 2011
update: I tried the svn trunk (r14684) and building .CDB works without the
EX_OSERR issue. Horray!
Is the trunk in a stable condition at r14684? I usually try to be a just
little behind the bleeding edge. ;-)
On Sun, Mar 20, 2011 at 5:59 AM, Jason E. Aten <j.e.aten at gmail.com> wrote:
> Arg. I'm so close to getting this working! Here I did an svn update to
> r14684 / r14469, and get an error in lib/compile-ccl.lisp about a 'Error:
> Foreign variable "EX_OSERR" not found'. I'll attach a full log with svn
> update details and a backtrace in case that helps.
> - Jason
> p.s. a couple of small things came up while I was trying to figure this
> a. is there a way to show the source for a function already defined? In
> googling I found some notes about *recor\
> d-source-file*, and CCL:*SAVE-SOURCE-LOCATIONS*, but I haven't figured out
> how to display the source for a functi\
> on. Is that possible?
> b. is there an option to automatically, upon error condition, go to the
> toplevel as if typing ctrl-d or :q, instead o\
> f to the nested repl every time. I make alot of mistakes(!) and just want
> to try again immediately, without the e\
> xtra keystroke of having to get out of the condition restart nested repl.
> Thank you, thank you!
> c. summary of attached log of svn update attempt:
> jaten at afarm:~/pkg/ccl$ ccl --no-init
> trying: /home/jaten/pkg/ccl/lx86cl64
> Welcome to Clozure Common Lisp Version 1.6 (LinuxX8664)!
> ? (ccl:rebuild-ccl :full t)
> Rebuilding Clozure Common Lisp using Version 1.6 (LinuxX8664)
> ;Building lisp-kernel ...
> ;Kernel built successfully.
> ;Compiling "/home/jaten/pkg/ccl/lib/systems.lisp"...
> ;Loading #P"/home/jaten/pkg/ccl/bin/systems.lx64fsl"...
> ;Compiling "/home/jaten/pkg/ccl/lib/compile-ccl.lisp"...
> Read error between positions 17010 and 17742 in
> > Error: Foreign variable "EX_OSERR" not found
> > While executing: %LOAD-VAR, in process listener(1).
> > Type :POP to abort, :R for a list of available restarts.
> > Type :? for other options.
> 1 >
> #hmm... do I have the fix to lib/db-io.lisp ? It looks like it should be
> there from the svn log...
> jaten at afarm:~/pkg/ccl/lib$ svn log db-io.lisp
> r14684 | gb | 2011-03-19 17:00:03 -0500 (Sat, 19 Mar 2011) | 2 lines
> Propagate r14525 to 1.6 branch.
> # umph... I don't know what do try next!?!
> On Sun, Mar 20, 2011 at 4:57 AM, Gary Byers <gb at clozure.com> wrote:
>> That was fixed in the trunk a few months ago but the change hadn't
>> been propagated to the 1.6 tree. It's there now.
>> On Sat, 19 Mar 2011, Jason E. Aten wrote:
>> Thank you for the fix on this, Gary.
>>> I tested it and it works. ?I can confirm that svn r72 of ffigen4 now
>>> for me on?ccl/x86-headers64/libc/C/populate.sh ?under Ubunutu 10.04 on
>>> I am still getting some kind of issue with the final assembly of .cdb
>>> (they are not produced) during ENCODE-FFI-TYPE. ?I try to run
>>> cc::parse-standard-ffi-files on the resulting :libc, and I get this
>>> ? (require "PARSE-FFI")
>>> ? (ccl::parse-standard-ffi-files :libc)
>>> #P"/home/jaten/pkg/ccl/x86-headers64/libc/C/usr/include/a\\.out.ffi" ...
>>> #P"/home/jaten/pkg/ccl/x86-headers64/libc/C/usr/include/aio.ffi" ...
>>> #P"/home/jaten/pkg/ccl/x86-headers64/libc/C/usr/include/aliases.ffi" ...
>>> ...(all the .ffi files are listed and seem to load okay, and then)....
>>> #P"/home/jaten/pkg/ccl/x86-headers64/libc/C/usr/include/wchar.ffi" ...
>>> #P"/home/jaten/pkg/ccl/x86-headers64/libc/C/usr/include/wctype.ffi" ...
>>> #P"/home/jaten/pkg/ccl/x86-headers64/libc/C/usr/include/wordexp.ffi" ...
>>> #P"/home/jaten/pkg/ccl/x86-headers64/libc/C/usr/include/xlocale.ffi" ...
>>> #P"/home/jaten/pkg/ccl/x86-headers64/libc/C/usr/include/zlib.ffi" ...
>>> > Error: value #<FFI-TRANSPARENT-UNION 286_/usr/include/wait.h
>>> #x302002F0059D> is not of the expected type FFI-UNION.
>>> > While executing: ENCODE-FFI-TYPE, in process listener(1).
>>> > Type :POP to abort, :R for a list of available restarts.
>>> > Type :? for other options.
>>> 1 >?
>>> In case it helps diagnose this, I've attached copies of
>>> ?and the ?~/pkg/ccl/x86-headers64/libc/C/usr/include/wait.ffi ?file
>>> generated by h-to-ffi.sh run under populate.sh with CFLAGS="-m64
>>> -D_GNU_SOURCE";export CFLAGS.
>>> Let me know if I can provide anything more.
>>> ?- Jason
>>> On Sat, Mar 19, 2011 at 4:01 PM, Gary Byers <gb at clozure.com> wrote:
>>> gcc-4.0.0 is several years old, but we (usually) don't care
>>> about that;
>>> what generally matters is that the gcc version in question
>>> follows the
>>> platform's ABI's rules about how structures are laid out and how
>>> fields are aligned. ?Older GCC versions are generally easier to
>>> (have fewer dependencies) than newer versions are, and on many
>>> we can patch 4.0.0 and get a working translator; that's what the
>>> in the ffigen4 svn trunk tries to do.
>>> The construct from /usr/include/bits/link.h that it's choking on
>>> it chokes for me as well, though I didn't notice) is the
>>> of the (relatively new) 256-bit "ymm" vector register type.
>>> doesn't believe that such a thing exists. ?It happens to be sort
>>> right about that (it was supposed to have been introduced in
>>> "Sandy Bridge" chips, which got delayed/recalled and may or may
>>> exist in shipping systems; I haven't followed it too closely)
>>> but the
>>> concept of 256-bit (and possibly larger) SIMD registers has been
>>> some Linux headers (and kernels/libraries) for the last few
>>> years, and
>>> we need to support that.
>>> I checked in a change to ffigen that seems to fix this.
>>> On Sat, 19 Mar 2011, Jason E. Aten wrote:
>>> Hmm... that does indeed look like the wiki page I was
>>> referencing. ?Is
>>> gcc-4.0.0 not the current version?
>>> Here's the exact script (with sequence of commands) that I
>>> wrote to preserve
>>> exactly how I went about acquiring and installing ffigen
>>> and h-to-ffi.sh. If
>>> you have trouble reproducing it, let me know. It's just a
>>> stock Ubuntu 10.04
>>> on x86_64, but I can give you a login on a remote box if
>>> need be, or get you
>>> a virtualbox image.
>>> jaten at AtenMBP-2:~/research/djitia$ cat install-ffigen.sh?
>>> svn co
>>> cd ffigen4/
>>> # example sudo
>>> 8664-gcc-4.0.0-2011-03-18-23-40-54.tar.gz -C /usr/local
>>> export TARBALL=`ls -1 | grep ffigen-bin`
>>> export HERE=`pwd`
>>> echo "installing now to: ? ?/usr/local/ffigen ? and ?
>>> /usr/local/bin/h-to-ffi.sh ? ...with sudo"
>>> echo "sudo tar xfz `pwd`/`ls -1 | grep ffigen-bin` -C
>>> sudo tar xfz `pwd`/`ls -1 | grep ffigen-bin` -C /usr/local
>>> On Sat, Mar 19, 2011 at 11:37 AM, Gary Byers
>>> <gb at clozure.com> wrote:
>>> ? ? ?Hmm. ?The Wiki page at
>>> ? ? ?<http://trac.clozure.com/ccl/wiki/BuildFFIGEN> is
>>> ? ? ?supposed to be the canonical reference that describes
>>> how to
>>> ? ? ?obtain/build/install
>>> ? ? ?the FFI translator. ?In the past, we've distributed
>>> sources and
>>> ? ? ?binaries via
>>> ? ? ?other means, but there aren't supposed to be any
>>> links to those
>>> ? ? ?older versions
>>> ? ? ?and I can't find any links in the documentation.
>>> ? ? ?The current version doesn't have any problem
>>> ? ? ?/usr/include/link.h
>>> ? ? ?(or with the SIMD vector type referenced in the
>>> included file),
>>> ? ? ?but I'd certainly
>>> ? ? ?believe that older versions did. ?If you got an older
>>> ? ? ?that'd explain
>>> ? ? ?it; if you remember how you got that version, we
>>> should fix any
>>> ? ? ?links to it
>>> ? ? ?so that they reference the Wiki page instead.
>>> ? ? ?On Sat, 19 Mar 2011, Jason E. Aten wrote:
>>> ? ? ?Thank you Raffael. ?I appreciate the pointer. I guess
>>> ? ? ?confirms #1, and
>>> ? ? ?answers #2. :-)
>>> ? ? ?For #3, I've managed to locate the source code for
>>> ? ? ?ffigen loader, and
>>> ? ? ?figured out that :SUBDIR is supposed to be :libc or
>>> ? ? ??or similar.
>>> ? ? ?However I do manage to have populate.sh run into an
>>> ? ? ?+++ /usr/include/link.h
>>> ? ? ?Need to create info for type:
>>> ? ? ??<vector_type 0x7fab52eacb60
>>> ? ? ??? ?type <real_type 0x7fab53619000 float SF
>>> ? ? ??? ? ? ?size <integer_cst 0x7fab535fba80 constant
>>> ? ? ?invariant 32>
>>> ? ? ??? ? ? ?unit size <integer_cst 0x7fab535fb5a0
>>> ? ? ?invariant 4>
>>> ? ? ??? ? ? ?align 32 symtab 18 alias set -1 precision 32
>>> ? ? ??? ? ? ?pointer_to_this <pointer_type
>>> ? ? ??? ?BLK
>>> ? ? ??? ?size <integer_cst 0x7fab536146f0 type
>>> ? ? ?0x7fab536015b0
>>> ? ? ?bit_size_type> constant invariant 256>
>>> ? ? ??? ?unit size <integer_cst 0x7fab535fb570 type
>>> ? ? ?<integer_type 0x7fab536014e0
>>> ? ? ?long unsigned int> constant invariant 32>
>>> ? ? ??? ?align 256 symtab 341 alias set -1 nunits 8>
>>> ? ? ?In file included from /usr/include/link.h:36:
>>> ? ? ?/usr/include/bits/link.h:68: internal compiler error:
>>> ? ? ?ffi_create_type_info, at ffi.c:428
>>> ? ? ?Please submit a full bug report,
>>> ? ? ?with preprocessed source if appropriate.
>>> ? ? ?See <URL:http://gcc.gnu.org/bugs.html> for
>>> ? ? ?where the relevant section from
>>> ? ? ?including line 68
>>> ? ? ?is this:
>>> ? ? ?/* Registers for entry into PLT on x86-64. ?*/
>>> ? ? ?# if __GNUC_PREREQ (4,0)
>>> ? ? ?typedef float La_x86_64_xmm __attribute__
>>> ? ? ?((__vector_size__ (16)));
>>> ? ? ?typedef float La_x86_64_ymm __attribute__
>>> ? ? ?((__vector_size__ (32))); ?/* line
>>> ? ? ?68 */
>>> ? ? ?# else
>>> ? ? ?typedef float La_x86_64_xmm __attribute__ ((__mode__
>>> ? ? ?(__V4SF__)));
>>> ? ? ?# endif
>>> ? ? ?Arg. What should I try? ?Is this the right place to
>>> ? ? ?this?
>>> ? ? ?Thank you.
>>> ? ? ?Jason
>>> ? ? ?On Sat, Mar 19, 2011 at 12:21 AM, Raffael Cavallaro
>>> ? ? ?<raffaelcavallaro at mac.com> wrote:
>>> ? ? ?? ? ?On Mar 19, 2011, at 1:09 AM, Jason E. Aten
>>> ? ? ?? ? ?> In order words, when two different threads
>>> need to
>>> ? ? ?be able to
>>> ? ? ?? ? ?name the same variable (after locking the thread
>>> ? ? ?inspects the
>>> ? ? ?? ? ?shared variable, possibly updates it, then
>>> ? ? ?the lock),
>>> ? ? ?? ? ?how do I tell lisp this is what I'd like?
>>> ? ? ?See section 4.8 of the documentation "Static
>>> ? ? ?e.g., (defstatic *foo* 3)
>>> ? ? ?It's an error to dynamically rebind a static
>>> variable; its
>>> ? ? ?value is
>>> ? ? ?always the same across all threads. Naturally, as you
>>> ? ? ?suggest, you'll
>>> ? ? ?want to avoid race conditions by using a lock or
>>> ? ? ?semaphore.
>>> ? ? ?warmest regards,
>>> ? ? ?Ralph
>>> ? ? ?Raffael Cavallaro
>>> ? ? ?raffaelcavallaro at me.com
>>> Jason E. Aten, Ph.D.
>>> Jason E. Aten, Ph.D.
> Jason E. Aten, Ph.D.
Jason E. Aten, Ph.D.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openmcl-devel