[Openmcl-devel] 3 questions - TLS the default? global thread-shared vars? .CDB gen broken?
Gary Byers
gb at clozure.com
Sun Mar 20 02:57:47 PDT 2011
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.
>
>
>
>
More information about the Openmcl-devel
mailing list