I can run ARM version pocl on our target board now, however, for vector float
operation, it has some errors "unreachable executed at ARMCodeEmitter.cpp". My
question is that for ARM, How mature is LLVM 3.1 ? or need any special
configuration. Otherwise, it won't be very useful
Regards,
Yi
________________________________
From: Pekka Jääskeläinen <[email protected]>
To: "[email protected]" <[email protected]>
Cc: Yi Ge <[email protected]>
Sent: Saturday, October 6, 2012 6:33 AM
Subject: Re: [pocl-devel] build pocl-0.6 on ARM board
On 10/05/2012 08:58 PM, Yi Ge wrote:
> But I can NOT run the examples, the issue is that inside clCreateKernel
> function, it calls the lt_dlopen, but it didn't return any errors, but exit
> inside the lt_dlopen, the descriptor_filename was verified correct. Because
> there is no error reported, I was baffled by it. Is there any advice for it?
Are you using the latest development branch, BTW? You should as there has
been a lots of improvements since 0.6. 'bzr co lp:pocl' is the way
to get it.
One problem with the dlopen call that loads the compiled kernel dynamic
library for execution is that it reports a file not found error even though
the reason is something else, e.g., unresolved symbols in the dynamic
module.
I encountered problems with the dlopen yesterday when I quickly tested porting
to the PowerPC of Cell on a Debian Sid installed in a PlayStation 3. The
problem there was that in the default powerpc32 compilation mode (of
Debian/ppc32) the kernels were still compiled in 64 bit mode and the dlopen
failed to load the kernel .so. It's probably because of not finding the correct
64 bit libraries required by the plugin, or perhaps the 32/64 compat of
PowerPC64 doesn't work that way around.
I got it working to some extent by forcing the 32-bit mode also to the
clang/LLVM. Also it seemed to work now in a Debian Sid for ppc64 (installed in
a chroot jail) in the PlayStation 3 without pocl modifications. However, there
were test failures which I didn't have time to debug yet.
You can check if your problem is caused by missing symbols by using
'nm parallel.so' in the final parallel kernel binary (remember
the POCL_LEAVE_TEMP_DIRS and POCL_TEMP_DIR envs, doc/envs.txt). Check for
symbols marked 'U'. In some cases it might happen that the built-in requires a
libm library function which is not linked in for some reason. The place to poke
is the 'run' implementation of the pocl-pthread.c device layer implementation.
Also I recall problems specific to ARM compilation from the ARM port
experiment. They were related to the multiple ways ARM binaries can handle
floats, which might make the ABIs incompatible in case the other library
is compiled with different float settings (soft float vs. hardware float).
This type of ABI incompatiblity might also cause such problems in dlopen().
I think I added some llc/linker switches to configure.ac specific for the arm
port which can be enabled with ./configure --enable-arm-cortex-a8. However, as
that experiment was almost a year ago things might have outdated.
-- --Pekka
------------------------------------------------------------------------------
The Windows 8 Center
In partnership with Sourceforge
Your idea - your app - 30 days. Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
_______________________________________________
pocl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pocl-devel
