[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
> out...
>
> 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
> /home/jaten/pkg/ccl/lib/compile-ccl.lisp.
> > 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
>>> works
>>> for me on?ccl/x86-headers64/libc/C/populate.sh ?under Ubunutu 10.04 on
>>> x86_64.
>>>
>>> I am still getting some kind of issue with the final assembly of .cdb
>>> files
>>> (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
>>> error:
>>>
>>> ? (require "PARSE-FFI")
>>> "PARSE-FFI"
>>> ("PARSE-FFI")
>>> ? (ccl::parse-standard-ffi-files :libc)
>>> #P"/home/jaten/pkg/ccl/x86-headers64/libc/C/usr/include/_G_config.ffi"
>>> ...
>>> #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
>>> /usr/include/wait.h
>>> ?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
>>> their
>>> fields are aligned. ?Older GCC versions are generally easier to
>>> build
>>> (have fewer dependencies) than newer versions are, and on many
>>> platforms
>>> we can patch 4.0.0 and get a working translator; that's what the
>>> code
>>> in the ffigen4 svn trunk tries to do.
>>>
>>> The construct from /usr/include/bits/link.h that it's choking on
>>> (and
>>> it chokes for me as well, though I didn't notice) is the
>>> description
>>> of the (relatively new) 256-bit "ymm" vector register type.
>>> ?ffigen
>>> doesn't believe that such a thing exists. ?It happens to be sort
>>> of
>>> right about that (it was supposed to have been introduced in
>>> Intel's
>>> "Sandy Bridge" chips, which got delayed/recalled and may or may
>>> not
>>> exist in shipping systems; I haven't followed it too closely)
>>> but the
>>> concept of 256-bit (and possibly larger) SIMD registers has been
>>> in
>>> 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.
>>> Thanks,
>>> Jason
>>>
>>> jaten at AtenMBP-2:~/research/djitia$ cat install-ffigen.sh?
>>> #!/bin/bash
>>> svn co
>>> http://svn.clozure.com/publicsvn/ffigen4/trunk/ffigen4
>>> cd ffigen4/
>>> wget
>>> http://ftp.gnu.org/gnu/gcc/gcc-4.0.0/gcc-core-4.0.0.tar.bz2
>>> wget
>>> http://ftp.gnu.org/gnu/gcc/gcc-4.0.0/gcc-objc-4.0.0.tar.bz2
>>> make
>>> # example sudo
>>> tarxfz/home/jaten/pkg/llvm28/llvm-2.8/tools/ldc2/ffigen/ffigen4/ffigen-bin-lin
>>>
>>> uxx
>>> 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
>>> /usr/local"
>>> 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
>>> translating
>>> ? ? ?/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
>>> version,
>>> ? ? ?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
>>> that
>>> ? ? ?confirms #1, and
>>> ? ? ?answers #2. :-)
>>>
>>> ? ? ?For #3, I've managed to locate the source code for
>>> the
>>> ? ? ?ffigen loader, and
>>> ? ? ?figured out that :SUBDIR is supposed to be :libc or
>>> :elf
>>> ? ? ??or similar.
>>>
>>> ? ? ?However I do manage to have populate.sh run into an
>>> issue:
>>>
>>> ? ? ?+++ /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
>>> constant
>>> ? ? ?invariant 4>
>>> ? ? ??? ? ? ?align 32 symtab 18 alias set -1 precision 32
>>> ? ? ??? ? ? ?pointer_to_this <pointer_type
>>> 0x7fab53619270>>
>>> ? ? ??? ?BLK
>>> ? ? ??? ?size <integer_cst 0x7fab536146f0 type
>>> <integer_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:
>>> in
>>> ? ? ?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
>>> instructions.
>>>
>>> ? ? ?where the relevant section from
>>> /usr/include/bits/link.h,
>>> ? ? ?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
>>> report
>>> ? ? ?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
>>> wrote:
>>>
>>> ? ? ?? ? ?> 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
>>> releases
>>> ? ? ?the lock),
>>> ? ? ?? ? ?how do I tell lisp this is what I'd like?
>>>
>>> ? ? ?See section 4.8 of the documentation "Static
>>> Variables"
>>>
>>> ? ? ?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...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20110320/c11e86d9/attachment.htm>
More information about the Openmcl-devel
mailing list