Re: GDB's OpenCL Tests

[Ulrich Weigand <uweigand@de.ibm.com>]

On Tue, Jun 02, 2020 at 10:01:25AM -0300, Luis Machado wrote:
> Since Ulrich Weigand (cc-ed) introduced this testcase, maybe he has some 
> input on how it is supposed to work, or how the whole infrastructure is 
> supposed to be configured.
> 
> I don't run those myself. We should probably fix this and make them easy 
> to run, with clear instructions on what is needed to get them going.
> 
> On 6/2/20 8:06 AM, Andrew Burgess wrote:
> > I wonder if anyone is regularly running the OpenCL tests for GDB?

Hi Andrew,

at this point OpenCL support in GDB is mostly dead code.

We added this feature many years back to support the IBM OpenCL
platform on the Cell Broadband Engine.  As Cell/B.E. support was
removed from GDB last year, I don't believe there's any target
currently available that can actually make use of GDB's OpenCL
support.

However, I left OpenCL language support as such in, just in case
someone might want to re-enable OpenCL platform support on some
other platform.

The main issue is that in addition to OpenCL *language* support
(which GDB still has, and which should hopefully be platform-
independent -- however it be a bit outdated and not yet support
the most recent OpenCL language versions), you also need support
for the *platform* that is running OpenCL code, in particular
to detect kernels being loaded etc.  This is somewhat comparable
to GDB's dynamic library code, and needs support from the OpenCL
platform run-time libraries to work.

Also, of course, it may be difficult (or impossible) to debug
OpenCL code running on some non-CPU accelerator.  (But GDB should
always be able to handle OpenCL code running on the main CPU,
assuming the platform run-time support is in place.)

> > I'm running Fedora 31.  Initially None of the OpenCL tests would run
> > due to the libOpenCL library being missing, so I installed the
> > packages `ocl-icd', `ocl-icd-devel', and `opencl-headers'.  After this
> > I did have libOpenCL.so, but things were still not working.

I'm not familiar with ocl-icd, which didn't exist yet back then ...
It may be possible to add platform support to GDB for this, but
this would require some work (both in GDB and in the library).

> > What I see is this pattern in basically every test:
> > 
> >    (gdb) tbreak testkernel
> >    Function "testkernel" not defined.
> >    Make breakpoint pending on future shared library load? (y or [n]) y
> >    Temporary breakpoint 1 (testkernel) pending.
> >    (gdb) PASS: gdb.opencl/datatypes.exp: Set pending breakpoint
> >    run
> >    ....
> >    [Inferior 1 (process 2840279) exited normally]
> >    (gdb) FAIL: gdb.opencl/datatypes.exp: run (the program exited)
> > 
> > The 'testkernel' seems to be the core entry point function within the
> > actual opencl program, so we never hit that symbol.

Yes, this would be expected if there's no platform support, so GDB
doesn't notice when compiled kernel code (and it's symbols/debug info)
shows up in the process address space.

> > So now I ran the test manually under GDB, break at 'exit' and then
> > 'rbreak testkernel', this sets 3 breakpoints for me.  Start the test
> > up again with 'run', and I hit one of the breakpoints, here's what I
> > see:
> > 
> >    Thread 25 "callfuncs" hit Breakpoint 3, 0x00007ffff7fc9354 in _pocl_kernel_testkernel_workgroup ()
> >       from /home/andrew/.cache/pocl/kcache/BA/OLMGEJJKCCPFCOMNNHDOJKFDNOKMKEPPCEIPJ/testkernel/16-1-1-goffs0-smallgrid/testkernel.so
> >    (gdb) bt
> >    #0  0x00007ffff7fc9354 in _pocl_kernel_testkernel_workgroup ()
> >       from /home/andrew/.cache/pocl/kcache/BA/OLMGEJJKCCPFCOMNNHDOJKFDNOKMKEPPCEIPJ/testkernel/16-1-1-goffs0-smallgrid/testkernel.so
> >    #1  0x00007ffff070fe6d in pocl_pthread_driver_thread () from /lib64/libpocl.so.2.5.0
> >    #2  0x00007ffff1d324e2 in start_thread () from /lib64/libpthread.so.0
> >    #3  0x00007ffff7d7a6a3 in clone () from /lib64/libc.so.6
> > 
> > I then use 'objdump -W' to look at the debug information in
> > testkernel.so, and it has no extra debug at all.

That seems like another platform/run-time issue, the run-time will
need to actually build kernels with debug info if there is supposed
to be debugging support.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com