it seems that pocl-kernel script somehow didn't convert kernel.bc into so file,
because when I used ldd to see the descriptor.so, it tells me that it is not a
dynamic executable
Regards,
Yi
________________________________
From: Yi Ge <[email protected]>
To: Pekka Jääskeläinen <[email protected]>;
"[email protected]" <[email protected]>
Sent: Monday, October 8, 2012 2:16 PM
Subject: Re: [pocl-devel] build pocl-0.6 on ARM board
Thanks for the response.
1. I compared the forloops -- descriptor.so files on X86 and my ARM board. I
saw some difference, but it is not because of undefined symbols.
Below is the one I got from ARM board
00008264 a _DYNAMIC
000082bc a _GLOBAL_OFFSET_TABLE_
000082d0 A __bss_end__
000082c8 A __bss_start
000082c8 A __bss_start__
000082d0 A __end__
000082cc B _arg_is_image
000082cc B _arg_is_local
000082cc B _arg_is_pointer
000082cc B _arg_is_sampler
000082d0 A _bss_end__
000082c8 A _edata
000082d0 A _end
000082c8 B _num_args
000082cc B _num_locals
You noticed there are two _bss_start__, in X86 there is only one, also, there
is __bss_end_ in the beginning, but for X86, there is no such thing.
Did it ring any bell for you? Thanks for the advice beforehand.
Also, the descriptors.so on X86 and ARM all come out from one kernel.bc file.
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
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
pocl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pocl-devel
