From: Luis Machado <luis.machado@linaro.org>
To: Andrew Burgess <andrew.burgess@embecosm.com>, gdb@sourceware.org
Cc: uweigand@de.ibm.com
Subject: Re: GDB's OpenCL Tests
Date: Tue, 2 Jun 2020 10:01:25 -0300 [thread overview]
Message-ID: <cf7b210c-767a-1f4b-701b-26f539f08977@linaro.org> (raw)
In-Reply-To: <20200602110615.GJ2242921@embecosm.com>
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 ##
>
next prev parent reply other threads:[~2020-06-02 13:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-02 11:06 Andrew Burgess
2020-06-02 13:01 ` Luis Machado [this message]
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=cf7b210c-767a-1f4b-701b-26f539f08977@linaro.org \
--to=luis.machado@linaro.org \
--cc=andrew.burgess@embecosm.com \
--cc=gdb@sourceware.org \
--cc=uweigand@de.ibm.com \
/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).