<div>Thank you for the fix on this, Gary.</div><div><br></div><div>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.</div>
<div><br></div><div>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:</div>
<div><br></div><div><div>? (require "PARSE-FFI")</div><div>"PARSE-FFI"</div><div>("PARSE-FFI")</div><div>? (ccl::parse-standard-ffi-files :libc)</div><div>#P"/home/jaten/pkg/ccl/x86-headers64/libc/C/usr/include/_G_config.ffi" ...</div>
<div>#P"/home/jaten/pkg/ccl/x86-headers64/libc/C/usr/include/a\\.out.ffi" ...</div><div>#P"/home/jaten/pkg/ccl/x86-headers64/libc/C/usr/include/aio.ffi" ...</div><div>#P"/home/jaten/pkg/ccl/x86-headers64/libc/C/usr/include/aliases.ffi" ...</div>
</div><div>...</div><div>...(all the .ffi files are listed and seem to load okay, and then)....</div><div>...</div><div><div>#P"/home/jaten/pkg/ccl/x86-headers64/libc/C/usr/include/wchar.ffi" ...</div><div>#P"/home/jaten/pkg/ccl/x86-headers64/libc/C/usr/include/wctype.ffi" ...</div>
<div>#P"/home/jaten/pkg/ccl/x86-headers64/libc/C/usr/include/wordexp.ffi" ...</div><div>#P"/home/jaten/pkg/ccl/x86-headers64/libc/C/usr/include/xlocale.ffi" ...</div><div>#P"/home/jaten/pkg/ccl/x86-headers64/libc/C/usr/include/zlib.ffi" ...</div>
</div><div>> Error: value #<FFI-TRANSPARENT-UNION 286_/usr/include/wait.h #x302002F0059D> is not of the expected type FFI-UNION.</div><div>> While executing: ENCODE-FFI-TYPE, in process listener(1).</div><div>
> Type :POP to abort, :R for a list of available restarts.</div><div>> Type :? for other options.</div><div>1 > </div><div><br></div><div>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.</div>
<div><br></div><div>Let me know if I can provide anything more.</div><div><br></div><div> - Jason</div><div><br></div><br><div class="gmail_quote">On Sat, Mar 19, 2011 at 4:01 PM, Gary Byers <span dir="ltr"><<a href="mailto:gb@clozure.com">gb@clozure.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">gcc-4.0.0 is several years old, but we (usually) don't care about that;<br>
what generally matters is that the gcc version in question follows the<br>
platform's ABI's rules about how structures are laid out and how their<br>
fields are aligned. Older GCC versions are generally easier to build<br>
(have fewer dependencies) than newer versions are, and on many platforms<br>
we can patch 4.0.0 and get a working translator; that's what the code<br>
in the ffigen4 svn trunk tries to do.<br>
<br>
The construct from /usr/include/bits/link.h that it's choking on (and<br>
it chokes for me as well, though I didn't notice) is the description<br>
of the (relatively new) 256-bit "ymm" vector register type. ffigen<br>
doesn't believe that such a thing exists. It happens to be sort of<br>
right about that (it was supposed to have been introduced in Intel's<br>
"Sandy Bridge" chips, which got delayed/recalled and may or may not<br>
exist in shipping systems; I haven't followed it too closely) but the<br>
concept of 256-bit (and possibly larger) SIMD registers has been in<br>
some Linux headers (and kernels/libraries) for the last few years, and<br>
we need to support that.<br>
<br>
I checked in a change to ffigen that seems to fix this.<div class="im"><br>
<br>
On Sat, 19 Mar 2011, Jason E. Aten wrote:<br>
<br>
</div><div><div></div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hmm... that does indeed look like the wiki page I was referencing. ?Is<br>
gcc-4.0.0 not the current version?<br>
Here's the exact script (with sequence of commands) that I wrote to preserve<br>
exactly how I went about acquiring and installing ffigen and h-to-ffi.sh. If<br>
you have trouble reproducing it, let me know. It's just a stock Ubuntu 10.04<br>
on x86_64, but I can give you a login on a remote box if need be, or get you<br>
a virtualbox image.<br>
Thanks,<br>
Jason<br>
<br>
jaten@AtenMBP-2:~/research/djitia$ cat install-ffigen.sh?<br>
#!/bin/bash<br>
svn co <a href="http://svn.clozure.com/publicsvn/ffigen4/trunk/ffigen4" target="_blank">http://svn.clozure.com/publicsvn/ffigen4/trunk/ffigen4</a><br>
cd ffigen4/<br>
wget <a href="http://ftp.gnu.org/gnu/gcc/gcc-4.0.0/gcc-core-4.0.0.tar.bz2" target="_blank">http://ftp.gnu.org/gnu/gcc/gcc-4.0.0/gcc-core-4.0.0.tar.bz2</a><br>
wget <a href="http://ftp.gnu.org/gnu/gcc/gcc-4.0.0/gcc-objc-4.0.0.tar.bz2" target="_blank">http://ftp.gnu.org/gnu/gcc/gcc-4.0.0/gcc-objc-4.0.0.tar.bz2</a><br>
make<br>
# example sudo tar xfz/home/jaten/pkg/llvm28/llvm-2.8/tools/ldc2/ffigen/ffigen4/ffigen-bin-linuxx<br>
8664-gcc-4.0.0-2011-03-18-23-40-54.tar.gz -C /usr/local<br>
export TARBALL=`ls -1 | grep ffigen-bin`<br>
export HERE=`pwd`<br>
<br>
echo "installing now to: ? ?/usr/local/ffigen ? and ?<br>
/usr/local/bin/h-to-ffi.sh ? ...with sudo"<br>
echo "sudo tar xfz `pwd`/`ls -1 | grep ffigen-bin` -C /usr/local"<br>
sudo tar xfz `pwd`/`ls -1 | grep ffigen-bin` -C /usr/local<br>
<br>
<br>
On Sat, Mar 19, 2011 at 11:37 AM, Gary Byers <<a href="mailto:gb@clozure.com" target="_blank">gb@clozure.com</a>> wrote:<br>
Hmm. ?The Wiki page at<br>
<<a href="http://trac.clozure.com/ccl/wiki/BuildFFIGEN" target="_blank">http://trac.clozure.com/ccl/wiki/BuildFFIGEN</a>> is<br>
supposed to be the canonical reference that describes how to<br>
obtain/build/install<br>
the FFI translator. ?In the past, we've distributed sources and<br>
binaries via<br>
other means, but there aren't supposed to be any links to those<br>
older versions<br>
and I can't find any links in the documentation.<br>
<br>
The current version doesn't have any problem translating<br>
/usr/include/link.h<br>
(or with the SIMD vector type referenced in the included file),<br>
but I'd certainly<br>
believe that older versions did. ?If you got an older version,<br>
that'd explain<br>
it; if you remember how you got that version, we should fix any<br>
links to it<br>
so that they reference the Wiki page instead.<br>
<br>
On Sat, 19 Mar 2011, Jason E. Aten wrote:<br>
<br>
Thank you Raffael. ?I appreciate the pointer. I guess that<br>
confirms #1, and<br>
answers #2. :-)<br>
<br>
For #3, I've managed to locate the source code for the<br>
ffigen loader, and<br>
figured out that :SUBDIR is supposed to be :libc or :elf<br>
?or similar.<br>
<br>
However I do manage to have populate.sh run into an issue:<br>
<br>
+++ /usr/include/link.h<br>
Need to create info for type:<br>
?<vector_type 0x7fab52eacb60<br>
?? ?type <real_type 0x7fab53619000 float SF<br>
?? ? ? ?size <integer_cst 0x7fab535fba80 constant<br>
invariant 32><br>
?? ? ? ?unit size <integer_cst 0x7fab535fb5a0 constant<br>
invariant 4><br>
?? ? ? ?align 32 symtab 18 alias set -1 precision 32<br>
?? ? ? ?pointer_to_this <pointer_type 0x7fab53619270>><br>
?? ?BLK<br>
?? ?size <integer_cst 0x7fab536146f0 type <integer_type<br>
0x7fab536015b0<br>
bit_size_type> constant invariant 256><br>
?? ?unit size <integer_cst 0x7fab535fb570 type<br>
<integer_type 0x7fab536014e0<br>
long unsigned int> constant invariant 32><br>
?? ?align 256 symtab 341 alias set -1 nunits 8><br>
In file included from /usr/include/link.h:36:<br>
/usr/include/bits/link.h:68: internal compiler error: in<br>
ffi_create_type_info, at ffi.c:428<br>
Please submit a full bug report,<br>
with preprocessed source if appropriate.<br>
See <URL:<a href="http://gcc.gnu.org/bugs.html" target="_blank">http://gcc.gnu.org/bugs.html</a>> for instructions.<br>
<br>
where the relevant section from /usr/include/bits/link.h,<br>
including line 68<br>
is this:<br>
<br>
/* Registers for entry into PLT on x86-64. ?*/<br>
# if __GNUC_PREREQ (4,0)<br>
typedef float La_x86_64_xmm __attribute__<br>
((__vector_size__ (16)));<br>
typedef float La_x86_64_ymm __attribute__<br>
((__vector_size__ (32))); ?/* line<br>
68 */<br>
# else<br>
typedef float La_x86_64_xmm __attribute__ ((__mode__<br>
(__V4SF__)));<br>
# endif<br>
<br>
Arg. What should I try? ?Is this the right place to report<br>
this?<br>
<br>
Thank you.<br>
<br>
Jason<br>
<br>
<br>
On Sat, Mar 19, 2011 at 12:21 AM, Raffael Cavallaro<br>
<<a href="mailto:raffaelcavallaro@mac.com" target="_blank">raffaelcavallaro@mac.com</a>> wrote:<br>
<br>
? ? ?On Mar 19, 2011, at 1:09 AM, Jason E. Aten wrote:<br>
<br>
? ? ?> In order words, when two different threads need to<br>
be able to<br>
? ? ?name the same variable (after locking the thread<br>
inspects the<br>
? ? ?shared variable, possibly updates it, then releases<br>
the lock),<br>
? ? ?how do I tell lisp this is what I'd like?<br>
<br>
See section 4.8 of the documentation "Static Variables"<br>
<br>
e.g., (defstatic *foo* 3)<br>
<br>
It's an error to dynamically rebind a static variable; its<br>
value is<br>
always the same across all threads. Naturally, as you<br>
suggest, you'll<br>
want to avoid race conditions by using a lock or<br>
semaphore.<br>
<br>
warmest regards,<br>
<br>
Ralph<br>
<br>
<br>
Raffael Cavallaro<br>
<a href="mailto:raffaelcavallaro@me.com" target="_blank">raffaelcavallaro@me.com</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
--<br>
Jason E. Aten, Ph.D.<br>
<br>
<br>
<br>
<br>
</blockquote>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Jason E. Aten, Ph.D.<br><br><br>