From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id +n2VNcd3QGn9bQIAWB0awg (envelope-from ) for ; Mon, 15 Dec 2025 16:04:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1765832647; bh=jFfrdl4m9IYcFSEWrkqGZq1+py1fFHUhNpEoAEJtgDI=; h=Date:Subject:From:To:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=U9vc1lzgmOnKD9QFJTciJUz4R74GvcAGN8GDLnjRz21RLn6ttIXrjqHm85G5XDxO/ Z6N4rhk4SoWrnBTiPZjnFdVq1P7kiKDgCZvEb4BYgZF698cMWBBqmnLdFWRs1TnHil oivbyyNRCJ6Ms9lv1h8siB368p4mx8a3bU7uJL98= Received: by simark.ca (Postfix, from userid 112) id C66C41E0BC; Mon, 15 Dec 2025 16:04:07 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=xKgQ3aiJ; dkim-atps=neutral Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 039D61E08D for ; Mon, 15 Dec 2025 16:04:06 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 7C5154BA2E05 for ; Mon, 15 Dec 2025 21:04:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7C5154BA2E05 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=xKgQ3aiJ Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 0305B4BA2E05 for ; Mon, 15 Dec 2025 21:03:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0305B4BA2E05 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0305B4BA2E05 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1765832615; cv=none; b=iG4EZ2GM/UB9fiTzVaeFEdtoAuqi/hfQxA5LmgAvF/ORbiX8RuVUvGdpLxu4i2C6ERf0zb+G6b3hrtTLeUxqG3XsYnMveweCfxl/hNteXqbdllJIKTPMGgvWypR3DonlJKvDD18F3V/t25iJ42d6sBjxYEtNdckrMmVHypGJl4E= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1765832615; c=relaxed/simple; bh=jFfrdl4m9IYcFSEWrkqGZq1+py1fFHUhNpEoAEJtgDI=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:From:To; b=x4szp55idmoXVCYkJVcud3SERv/YNJ5ktAqXFOHDzxCJyeE4aK1VziWijj23Dd9k13Roh1SuttEEyinzHCPN/RH0JBWnJuj8nTRrlipQgNwLpbx0xl+JkksG6CV0+wQOJORQQedTf3eBGzS1CsNcR7qfeoKFETPwenfhhH3pbhY= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0305B4BA2E05 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1765832614; bh=jFfrdl4m9IYcFSEWrkqGZq1+py1fFHUhNpEoAEJtgDI=; h=Date:Subject:From:To:References:In-Reply-To:From; b=xKgQ3aiJe89NDCnbZFol5/kexI+B/j+dBYhASOAdvqOD8x1J/WYYcM4CEYcBJ8IJ4 twxOVTYmTXGxTKFDVZBhxUfKsnvQ1eGuUnlZdEA8+sjjKkifZ1wAR5ecO5lKvQI7qx 9/63t1RORYhrdh3z/B+AbI6iLnI/nvsF/87zFD+I= Received: by simark.ca (Postfix) id 787DF1E08D; Mon, 15 Dec 2025 16:03:34 -0500 (EST) Message-ID: <83d2ce00-2c75-4037-a61c-401a4839aecb@simark.ca> Date: Mon, 15 Dec 2025 16:03:33 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 05/44] gdb, gdbserver, gdbsupport: add 'device' tag to XML target description From: Simon Marchi To: Tankut Baris Aktemur , gdb-patches@sourceware.org, Markus Metzger References: <20250801-upstream-intelgt-mvp-v3-0-59ce0f87075b@intel.com> <20250801-upstream-intelgt-mvp-v3-5-59ce0f87075b@intel.com> Content-Language: fr In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 12/9/25 4:27 PM, Simon Marchi wrote: > On 8/1/25 5:37 AM, Tankut Baris Aktemur wrote: >> From: Nils-Christian Kempke >> >> Add tag to the XML target description. The tag is a list of >> device attributes. The extension enables passing device information >> within the target description XML sent from gdbserver to gdb. > > The dtd change allows a single in the target description. When > (and if) you do multi-device debugging, you connect one inferior per > device? > > From the ROCm perspective: if we ever want to support remote debugging > (no concrete plans, but we want to keep the door open to it in the > design) and we end up using this attribute, I suppose we'll want to be > able to use multiple tags, since we do everything in a single > inferior. If so, it would be easier to support that possibility from > the start. I talked about that with my team, and what I proposed doesn't make sense. The entire target description describes just one arch, it wouldn't make sense to have multiple devices of possibly different arches in it. In ROCgdb, we have an "info agents" command, which lists the agents (devices) available to the current inferior (process). You can, for instance, stop at main(), and then type "info agents" to get the list. Therefore, I presume that we would instead need a new kind of query, "get me the list of devices", and that query could re-use the XML device format proposed in this patch. Another question I have is whether the low-level details specific to one device should really belong there in the target description. In other words, imagine that you debug with two identical devices simultaneously, should the target descriptions for both devices be identical? I tend to think that they should. Perhaps things like pci_slot shouldn't be in the target description, but in a separate "device" concept outside target descriptions. Things like vendor_id and target_id allow inferring details about the architecture, so I understand why it would be in there. Simon