Various issues with Clang and libc++ while playing with OpenCL (FYI)

[Jean-Sébastien Pédron]

On 05.03.2014 21:28, Dimitry Andric wrote:
>> 2. Mesa's configure script is looking for stddef.h here:
>>   /usr/local/llvm34/lib/clang/3.4/include
>>
>>   LLVM/Clang ports don't install this file. I just added a symlink to
>>   /usr/include/stddef.h and Mesa was happy. I still need to check how
>>   it goes if I remove the check and the symlink. But perhaps Mesa is
>>   right to expect this header (and maybe other) in this directory, I
>>   don't know.
> 
> (...)
> 
> On the other hand, I don't really understand why Mesa wants to know
> *where* a header is exactly located.  Normally, in configure scripts or
> similar, you are only interested in whether the compiler can find it or
> not.

I removed the check for stddef.h and everything build fine. It could be
a test tailored for some Linux distributions.

>> 3. Our base libc++ has a bug in the <functional> header. I posted a PR
>>   on Mesa bug tracker here, before I found out it was a problem with
>>   libc++:
>>   https://bugs.freedesktop.org/show_bug.cgi?id=75505
> 
> I applied that fix to head in r262805, and I will MFC it after 3 days.

I rebuild world and confirm that I don't need to modify <functional>
anymore.

>> 4. At runtime, any OpenCL program segfaults in libc++ (I don't have the
>>   stack trace at hand and can't remember what it was... Something with
>>   basic_string).
>>
>> When using libc++ from ports (devel/libc++, r200683) and the work around
>> for problem #1, Clover builds and OpenCL programs run fine.
> 
> Hm, this is unfortunate.  I'm interested in where the difference comes
> from, and I would ideally like to fix any problem with libc++ in base.

I reproduced the crash but can't restore a working state now. It's on a
different computer (newer 11-CURRENT, same libclc/Mesa/OpenCL program)
and the crash is a bus error, not a segfault.

Here's the backtrace:
http://people.freebsd.org/~dumbbell/radeonkms/opencl-crash-1.txt

> Can you point me (privately if you like) to some info on how to build
> and reproduce?

On a computer with WITH_NEW_XORG enabled and a Intel or Radeon GPU (HD
5000+), driven by i915kms/radeonkms (though I didn't try on Intel hardware):

1. You need libdevq:
     git clone https://github.com/freebsd/libdevq.git

   It uses autotools:
     autoreconf -vif
     ./configure --prefix=$PREFIX
     make
     make install

   (I use the same $PREFIX in the following commands)

2. You need libclc:
     git clone http://llvm.org/git/libclc.git

   You can configure it like this:
     python ./configure.py \
      --with-llvm-config=/usr/local/bin/llvm-config34 \
      --prefix=$PREFIX
     gmake
     gmake install

   Now is a good time to present you another problem I have with clang
   3.4: it eats 100% CPU when building utils/prepare-builtins.cpp and
   never return. I couldn't reproduce the problem when I wrote my
   original mail (the only time it worked), that's why I didn't mention
   it. But now, it's back.

   Here, I use an older commit and clang 3.3:
     git checkout c002f62bf03f093521c52e2816e4881afc49ef40
     python ./configure.py \
      --with-llvm-config=/usr/local/bin/llvm-config33 \
      --prefix=$PREFIX

3. You need Mesa:
     git clone -b mesa-10.1-rc2-freebsd \
      https://github.com/dumbbell/mesa.git

   To build Mesa, you'll need several ports, some of them comes from
   the xorg-dev ports tree:
     svn co https://trillian.chruetertee.ch/svn/ports/trunk

   Unfortunately, I don't have a ports list at hand... Try to run
   Mesa's configure script and install ports as required. And install
   them from xorg-dev first; if the port isn't in xorg-dev, take the
   one from /usr/ports.

   Here the configure line I use:
     (in checkout dir)
     autoreconf -vif

     (in checkout dir or separate build dir)
     /path/to/configure LLVM_CONFIG=/usr/local/bin/llvm-config34 \
      PKG_CONFIG_PATH=$PREFIX/share/pkgconfig:$PREFIX/lib/pkgconfig \
      --enable-texture-float --enable-gles2 --enable-osmesa \
      --enable-egl --enable-vdpau --enable-shared-glapi \
      --enable-glx-tls --enable-gallium-llvm --with-llvm-shared-libs \
      --enable-dri --enable-gbm --enable-r600-llvm-compiler \
      --with-egl-platforms=x11,drm \
      --with-gallium-drivers=radeonsi,swrast,r600,r300,nouveau \
      --enable-opencl --prefix=$PREFIX CFLAGS="-g -O0" CXXFLAGS="-g -O0"

     gmake
     gmake install

4. And some OpenCL programs:
     svn co http://opencl-book-samples.googlecode.com/svn/trunk

     (in a separate build dir)
     cmake -DOPENCL_LIBRARIES=$PREFIX/lib/libOpenCL.so.1 \
      -DOPENCL_INCLUDE_DIRS=$PREFIX/include -DCMAKE_BUILD_TYPE=Debug \
      /path/to/svn-checkout
     gmake

5. Run an OpenCL program:
     cd src/Chapter_2/HelloWorld
     DISPLAY=:0 ./HelloWorld

   An OpenCL requires a running X server, because only the server is
   allowed to access the CPU (without an X server, the program will
   fail with Permission denied).

I hope I didn't forgot something. I'm available on IRC (as dumbbell or
dumbbell-) in any case. My laptop is currently on stable/9; I could
setup an account for you once rebooted on -CURRENT, if you don't want to
bother with this awful procedure.

-- 
Jean-Sébastien Pédron

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-toolchain/attachments/20140307/0b643cfe/attachment.sig>