GDB's OpenCL Tests

GDB's OpenCL Tests

[Andrew Burgess]

I wonder if anyone is regularly running the OpenCL tests for GDB?

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 was mostly looking at the gdb.opencl/callfuncs.exp test, just
because it was the first test file, but I don't believe it is anything
special, in fact, the failures I was seeing came from the file
gdb/testsuite/lib/opencl.exp function skip_opencl_tests, when we're
just checking if opencl is supported or not.

The compile was failing with this message:

  /usr/include/CL/cl_version.h:34:9: note: #pragma message: cl_version.h: CL_TARGET_OPENCL_VERSION is not defined. Defaulting to 220 (OpenCL 2.2)
   34 | #pragma message("cl_version.h: CL_TARGET_OPENCL_VERSION is not defined. Defaulting to 220 (OpenCL 2.2)")
      |         ^~~~~~~

This is actually just a warning, but this is still enough to cause
GDB's testsuite to abandon the build.

A quick google, and "random internet stranger" recommended adding
something like:

   #define CL_TARGET_OPENCL_VERSION 120

to the offending source files, so I added this to:

  gdb/testsuite/lib/cl_util.c
  gdb/testsuite/lib/opencl_hostapp.c

I'm aware that at this point I'm just making random changes, so it's
not really surprising that nothing after this works, but lets push
on...

.... success, things now compile, but, almost all the tests are still
failing.

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.

It was at this point that I started to grow suspicious that nobody is
running these tests much (or at all?), the gdb.opencl/callfuncs.exp
test contains this gem:

  gdb_load ${objdir}/${subdir}/${testfile}

Which doesn't take account of the /output/ directory that was added
into the directory structure ages ago.  I applied patch #1 (below) to
fix this.

Still not hitting the testkernel symbol...

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.

So, my questions:

 - Can anyone successfully run some or all of the OpenCL tests?

 - And can anyone give me any hints on what I might need to do to get
   the tests running?

Thanks,
Andrew

---

## START - Patch 1 ##

diff --git a/gdb/testsuite/gdb.opencl/callfuncs.exp b/gdb/testsuite/gdb.opencl/callfuncs.exp
index cf418d16582..1452c403c90 100644
--- a/gdb/testsuite/gdb.opencl/callfuncs.exp
+++ b/gdb/testsuite/gdb.opencl/callfuncs.exp
@@ -33,12 +33,7 @@ if { [gdb_compile_opencl_hostapp "${clprogram}" "${testfile}" "" ] != "" } {
     return -1
 }
 
-gdb_exit
-gdb_start
-
-# Load the OpenCL app
-gdb_reinitialize_dir $srcdir/$subdir
-gdb_load ${objdir}/${subdir}/${testfile}
+clean_restart ${testfile}
 
 # Set breakpoint at the OpenCL kernel
 gdb_test "tbreak testkernel" \

## END - Patch 1 ##

Re: GDB's OpenCL Tests

[Luis Machado]

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?
> 
> 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 was mostly looking at the gdb.opencl/callfuncs.exp test, just
> because it was the first test file, but I don't believe it is anything
> special, in fact, the failures I was seeing came from the file
> gdb/testsuite/lib/opencl.exp function skip_opencl_tests, when we're
> just checking if opencl is supported or not.
> 
> The compile was failing with this message:
> 
>    /usr/include/CL/cl_version.h:34:9: note: #pragma message: cl_version.h: CL_TARGET_OPENCL_VERSION is not defined. Defaulting to 220 (OpenCL 2.2)
>     34 | #pragma message("cl_version.h: CL_TARGET_OPENCL_VERSION is not defined. Defaulting to 220 (OpenCL 2.2)")
>        |         ^~~~~~~
> 
> This is actually just a warning, but this is still enough to cause
> GDB's testsuite to abandon the build.
> 
> A quick google, and "random internet stranger" recommended adding
> something like:
> 
>     #define CL_TARGET_OPENCL_VERSION 120
> 
> to the offending source files, so I added this to:
> 
>    gdb/testsuite/lib/cl_util.c
>    gdb/testsuite/lib/opencl_hostapp.c
> 
> I'm aware that at this point I'm just making random changes, so it's
> not really surprising that nothing after this works, but lets push
> on...
> 
> .... success, things now compile, but, almost all the tests are still
> failing.
> 
> 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.
> 
> It was at this point that I started to grow suspicious that nobody is
> running these tests much (or at all?), the gdb.opencl/callfuncs.exp
> test contains this gem:
> 
>    gdb_load ${objdir}/${subdir}/${testfile}
> 
> Which doesn't take account of the /output/ directory that was added
> into the directory structure ages ago.  I applied patch #1 (below) to
> fix this.
> 
> Still not hitting the testkernel symbol...
> 
> 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.
> 
> So, my questions:
> 
>   - Can anyone successfully run some or all of the OpenCL tests?
> 
>   - And can anyone give me any hints on what I might need to do to get
>     the tests running?
> 
> Thanks,
> Andrew
> 
> ---
> 
> ## START - Patch 1 ##
> 
> diff --git a/gdb/testsuite/gdb.opencl/callfuncs.exp b/gdb/testsuite/gdb.opencl/callfuncs.exp
> index cf418d16582..1452c403c90 100644
> --- a/gdb/testsuite/gdb.opencl/callfuncs.exp
> +++ b/gdb/testsuite/gdb.opencl/callfuncs.exp
> @@ -33,12 +33,7 @@ if { [gdb_compile_opencl_hostapp "${clprogram}" "${testfile}" "" ] != "" } {
>       return -1
>   }
>   
> -gdb_exit
> -gdb_start
> -
> -# Load the OpenCL app
> -gdb_reinitialize_dir $srcdir/$subdir
> -gdb_load ${objdir}/${subdir}/${testfile}
> +clean_restart ${testfile}
>   
>   # Set breakpoint at the OpenCL kernel
>   gdb_test "tbreak testkernel" \
> 
> ## END - Patch 1 ##
> 

Re: GDB's OpenCL Tests

[Ulrich Weigand]

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

Re: GDB's OpenCL Tests

[Andrew Burgess]

* 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