From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) by sourceware.org (Postfix) with ESMTPS id 557D53857C62 for ; Thu, 21 Jan 2021 08:08:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 557D53857C62 Received: by mail-lj1-x22c.google.com with SMTP id u11so1410173ljo.13 for ; Thu, 21 Jan 2021 00:08:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HkhKkuAsRWLiSIGGo6GoahigfnkOfuofXLgsf6U/QzM=; b=RtNpiAhEMPoy4gxpOCXigC4+rwtxhoYIT6/J7imq/3JVwtPUsQb23WbY+1dpxUmdxy 7Y0jKyOTmemy1wRVr1C9YDXsh2EfT9Cfxymn4YtubTzwfYv7wevyzemg16Ni+M7R+hJV FsizH17sQ3qwU2t/J70FeL5HuOCvVVQ5jty9V0DWKCZKPqK6nnO6xAdd+FfidAxumMHA 3FpUQjwE+4+Tmgs29cULwlQJE3Ij7eHOQ1wYxzziTRMuJ/YuCD4M76/x3pbiCtZhpYvt Juc67D45HmGcnKDD0mpCDTUFV/AYavv8HQuEHEnoLVYEbrZGTvSqRgSYvflpJO3HzK92 Euzg== X-Gm-Message-State: AOAM533fW+1/7Yc4zwclgpX5TtIRTxqJArIWicLERRNNYiw0pcmo3+YG 9HO70gMgAsa1c575hKqjekLXE4RX/5x9/TXdCv0= X-Google-Smtp-Source: ABdhPJzwz1L/Fs1DPtk6XNfGHMngWCK7v2+ncJkbNK7VFZIFb5JEkgrQnjo8RM44RadvqLy6KCEq4h/ARrV5vqtN3bw= X-Received: by 2002:a2e:b556:: with SMTP id a22mr6041562ljn.264.1611216511413; Thu, 21 Jan 2021 00:08:31 -0800 (PST) MIME-Version: 1.0 References: <601fecb1-538b-13b9-8974-f92ef8ef5ca5@polymtl.ca> In-Reply-To: From: Rajinikanth Pandurangan Date: Thu, 21 Jan 2021 00:08:19 -0800 Message-ID: Subject: Re: GDB with PCIe device To: "Aktemur, Tankut Baris" Cc: Simon Marchi , "gdb@sourceware.org" , "Metzger, Markus T" , "Saiapova, Natalia" , "Strasuns, Mihails" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, KAM_SHORT, RCVD_IN_DNSWL_NONE, 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 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Thu, 21 Jan 2021 08:08:35 -0000 Thanks Simon and Aktemur for the details and pointers. What is the role of gdbserver here? I thought its needed only when gdb client and target machines are connected via serial/ethernet. Do we need gdbserver when we debug GPU kernels that are just over pcie? Thanks in advance! On Mon, Jan 11, 2021 at 1:31 AM Aktemur, Tankut Baris < tankut.baris.aktemur@intel.com> wrote: > On Friday, January 8, 2021 4:18 PM, Simon Marchi wrote: > > On 2020-12-26 1:48 a.m., Rajinikanth Pandurangan via Gdb wrote: > > > Hello, > > > > > > As per my understanding, gdb calls ptrace system calls which intern > uses > > > kernel implementation of architecture specific action (updating debug > > > registers,reading context memory...) to set breakpoints, and so on. > > > > > > But in case of running gdb with PCIe devices such as gpu or fpga, how > does > > > the hardware specific actions are being done? > > > > > > Should device drivers provide ptrace equivalent kernel implementation? > > > > > > Could any of the gdb gurus shed some light on debug software stacks in > > > debugging software that runs on one of the mentioned pcie devices? > > > > > > Thanks in advance, > > > > > > > One such gdb port that is in development is ROCm-GDB, by AMD: > > > > https://github.com/ROCm-Developer-Tools/ROCgdb > > > > It uses a helper library to debug the GPU threads: > > > > https://github.com/ROCm-Developer-Tools/ROCdbgapi > > > > I don't want to get too much into how this library works, because I'm > > sure I'll say something wrong / misleading. You can look at the code. > > But I'm pretty sure the GPU isn't debugged through ptrace. > > The library communicates with the kernel driver somehow, however. > > > > So, the GPU devices can use whatever debug interface, as long as a > > corresponding target exist in GDB to communicate with it. > > > > Today, one GDB can communicate with multiple debugging target, but only > > with one target per inferior. So you can be debugging a local program > > while debugging another remote program. > > We (Intel) use this approach. The host program that runs on the CPU is > represented as an inferior with the native target, and the kernel that > runs on the GPU is represented as another inferior with a remote target. > The remote target is connected to an instance of gdbserver that uses a > GPU-specific debug interface, which is not ptrace. > > A high-level presentation is available at > https://dl.acm.org/doi/abs/10.1145/3388333.3388646 > in case you want more information. > > Regards > -Baris > > > > > In the GPU / coprocessor programming world, the model is often that you > > run a program on the host, which spawns some threads on the GPU / > > coprocessor. From the point of view of the user, the threads on the host > > and the threads on the GPU / coprocessor belong to the same program, so > > would ideally appear in the same inferior. ROCm-GDB does this, but it's > > still done in a slightly hackish way, where the target that talks to the > > GPU is installed in the "arch" stratum (this is GDB internal stuff) of > > the inferior's target stack and hijacks the calls to the native Linux > > target. > > > > The better long term / general solution is probably to make GDB able to > > connect to multiple debug targets for a single inferior. > > > > Simon > > > > Intel Deutschland GmbH > Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany > Tel: +49 89 99 8853-0, www.intel.de > Managing Directors: Christin Eisenschmid, Gary Kershaw > Chairperson of the Supervisory Board: Nicole Lau > Registered Office: Munich > Commercial Register: Amtsgericht Muenchen HRB 186928 >