public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Burgess <andrew.burgess@embecosm.com>
To: gdb@sourceware.org
Subject: GDB's OpenCL Tests
Date: Tue, 2 Jun 2020 12:06:15 +0100	[thread overview]
Message-ID: <20200602110615.GJ2242921@embecosm.com> (raw)

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

             reply	other threads:[~2020-06-02 11:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-02 11:06 Andrew Burgess [this message]
2020-06-02 13:01 ` Luis Machado
2020-06-03 10:35   ` Ulrich Weigand
2020-06-03 11:26     ` Andrew Burgess

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200602110615.GJ2242921@embecosm.com \
    --to=andrew.burgess@embecosm.com \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).