From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by sourceware.org (Postfix) with ESMTPS id 440323851C1F for ; Wed, 3 Jun 2020 11:26:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 440323851C1F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=andrew.burgess@embecosm.com Received: by mail-wr1-x436.google.com with SMTP id x6so1910451wrm.13 for ; Wed, 03 Jun 2020 04:26:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=lRXjGZao/dFlk+fHO+1kQwh/dxVWc8xCF8kD+x1cJ2w=; b=eo/CP+lCwgN89PArZ5pm79/ge1xhfvOF4knR57QCaAAQXji7c2xj8snGleD3BjI3VD HJRNPeFtat5Un+u+cNpPS3OT0QEzzmu8Xfh8ifVVC5bokNb8hckC4o/yXjRwJnJOKDRO JrPgYUxhcCRjh76wZv1rA+qqSIo7B0g+oWxumlEd8kWJCGavtBo2eX0fOP70sM00zgAp l0BrXEQyl8CLAhSYzZwej/hKPcN2JNH4n1uHQIOMBmVEXBQRZNxcmfGGdAbPl25aCAgX 7rHxUCG39RvtUyZ4rXhCJyiOT/SZmSpAq/Ia4fOKLdvGG+X2z42sHLdRXlyuoZew5qi5 hUpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=lRXjGZao/dFlk+fHO+1kQwh/dxVWc8xCF8kD+x1cJ2w=; b=m/xX/TQ/o6EVKiOQOfDW7AeRxZpopfd6636PAeaxP/d4gsUAh4y+ewyCMEUf43EsUh DhvdCOnIeblPIgEp4yoOclHBMA0I0v4E/Kb7/Qx64f8yatzAjrR+tIgBpjeTP/beS4fu q6Wu+JGXcgv/sW2r3EW6627yZMQVlFDQk4bHh1AiRe7JdVa3Ciq4Q+LI3fg9uPLRmSTp /dCGUu9KbqPCdDZQrhrrnReMP6eRfG/L4SxrPzj9ihzGL+UqfFx+aereqeVoH62GcG28 ViIgtTLdWasVtmeFnGtwMV7pxAxb0WJstxRR9lRFozixeSr6IG04ptIZmW8yw7HSkKqt suQw== X-Gm-Message-State: AOAM530O4X/KASJivDOmHGb+qNNN2vb53oFgZ/exV87Jg4cD6BEkW1u5 N9CBADwMJ2uWSN+2ELO9AApQag== X-Google-Smtp-Source: ABdhPJxSKk5nK0QpL/sAHdnQHjX15v0dxW5o5FbfrqWL72VruMEgV0jQcQOO162VE1iBYP0zkjyU1Q== X-Received: by 2002:adf:f68d:: with SMTP id v13mr28539389wrp.291.1591183565107; Wed, 03 Jun 2020 04:26:05 -0700 (PDT) Received: from localhost (host86-128-12-16.range86-128.btcentralplus.com. [86.128.12.16]) by smtp.gmail.com with ESMTPSA id a1sm2664854wmd.28.2020.06.03.04.26.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jun 2020 04:26:04 -0700 (PDT) Date: Wed, 3 Jun 2020 12:26:02 +0100 From: Andrew Burgess To: Ulrich Weigand Cc: Luis Machado , gdb@sourceware.org Subject: Re: GDB's OpenCL Tests Message-ID: <20200603112602.GK2242921@embecosm.com> References: <20200602110615.GJ2242921@embecosm.com> <20200603103557.GA18878@oc3748833570.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200603103557.GA18878@oc3748833570.ibm.com> X-Operating-System: Linux/5.5.17-200.fc31.x86_64 (x86_64) X-Uptime: 12:23:33 up 44 days, 1:58, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no 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 11:26:07 -0000 * Ulrich Weigand [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