From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 5432839730F0 for ; Fri, 8 Jan 2021 15:17:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5432839730F0 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 108FHgB0030493 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 8 Jan 2021 10:17:47 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 108FHgB0030493 Received: from [10.0.0.213] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id CAE601E4F4; Fri, 8 Jan 2021 10:17:41 -0500 (EST) Subject: Re: GDB with PCIe device To: Rajinikanth Pandurangan , gdb@sourceware.org References: From: Simon Marchi Message-ID: <601fecb1-538b-13b9-8974-f92ef8ef5ca5@polymtl.ca> Date: Fri, 8 Jan 2021 10:17:41 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Fri, 8 Jan 2021 15:17:42 +0000 X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, 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: Fri, 08 Jan 2021 15:17:50 -0000 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. 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