[Openmcl-devel] 3 questions - TLS the default? global thread-shared vars? .CDB gen broken?

Jason E. Aten j.e.aten at gmail.com
Sat Mar 19 21:39:17 UTC 2011


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 tar
>> xfz/home/jaten/pkg/llvm28/llvm-2.8/tools/ldc2/ffigen/ffigen4/ffigen-bin-linuxx
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.clozure.com/pipermail/openmcl-devel/attachments/20110319/a4cebe00/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wait.h
Type: text/x-chdr
Size: 22 bytes
Desc: not available
URL: <http://lists.clozure.com/pipermail/openmcl-devel/attachments/20110319/a4cebe00/attachment.h>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wait.ffi
Type: application/octet-stream
Size: 79315 bytes
Desc: not available
URL: <http://lists.clozure.com/pipermail/openmcl-devel/attachments/20110319/a4cebe00/attachment.obj>


More information about the Openmcl-devel mailing list