From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id ACECE383F855 for ; Wed, 3 Jun 2020 10:38:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org ACECE383F855 Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 053AVtVd094489; Wed, 3 Jun 2020 06:38:13 -0400 Received: from ppma04ams.nl.ibm.com (63.31.33a9.ip4.static.sl-reverse.com [169.51.49.99]) by mx0a-001b2d01.pphosted.com with ESMTP id 31dfmmxm3f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 Jun 2020 06:38:12 -0400 Received: from pps.filterd (ppma04ams.nl.ibm.com [127.0.0.1]) by ppma04ams.nl.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 053AUI0B030678; Wed, 3 Jun 2020 10:36:00 GMT Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by ppma04ams.nl.ibm.com with ESMTP id 31bf47yu6a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 Jun 2020 10:36:00 +0000 Received: from d06av22.portsmouth.uk.ibm.com (d06av22.portsmouth.uk.ibm.com [9.149.105.58]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 053AZwZC48693480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 3 Jun 2020 10:35:58 GMT Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3B72E4C044; Wed, 3 Jun 2020 10:35:58 +0000 (GMT) Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2139E4C040; Wed, 3 Jun 2020 10:35:58 +0000 (GMT) Received: from oc3748833570.ibm.com (unknown [9.145.10.133]) by d06av22.portsmouth.uk.ibm.com (Postfix) with ESMTP; Wed, 3 Jun 2020 10:35:58 +0000 (GMT) Received: by oc3748833570.ibm.com (Postfix, from userid 1000) id 5810BD802F5; Wed, 3 Jun 2020 12:35:57 +0200 (CEST) Date: Wed, 3 Jun 2020 12:35:57 +0200 From: Ulrich Weigand To: Luis Machado Cc: andrew.burgess@embecosm.com, gdb@sourceware.org Subject: Re: GDB's OpenCL Tests Message-ID: <20200603103557.GA18878@oc3748833570.ibm.com> References: <20200602110615.GJ2242921@embecosm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-03_11:2020-06-02, 2020-06-03 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 mlxlogscore=999 lowpriorityscore=0 malwarescore=0 suspectscore=0 adultscore=0 cotscore=-2147483648 bulkscore=0 phishscore=0 clxscore=1011 impostorscore=0 spamscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006030079 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 10:38:17 -0000 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