Re: GDB's OpenCL Tests

[Andrew Burgess <andrew.burgess@embecosm.com>]

* Ulrich Weigand <uweigand@de.ibm.com> [2020-06-03 12:35:57 +0200]:

> 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.

Ulrich,

Thanks for the detailed status summary. I'll leave this be for now
them.

My interest was ensuring that I didn't break any language features as
I mess with GDB's language internals, but it sounds like a non-trivial
task to test OpenCL.

Thanks again,

Andrew




> 
> 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