From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id Kl4jHQhQ/WlCsSAAWB0awg (envelope-from ) for ; Thu, 07 May 2026 22:52:56 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=polymtl.ca header.i=@polymtl.ca header.a=rsa-sha256 header.s=oct2025 header.b=mywVrOJy; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 663D21E093; Thu, 07 May 2026 22:52:56 -0400 (EDT) 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 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 C78C31E093 for ; Thu, 07 May 2026 22:52:55 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3E0534BA2E20 for ; Fri, 8 May 2026 02:52:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3E0534BA2E20 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=polymtl.ca header.i=@polymtl.ca header.a=rsa-sha256 header.s=oct2025 header.b=mywVrOJy Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 8BC374BA2E1C for ; Fri, 8 May 2026 02:52:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8BC374BA2E1C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=polymtl.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=polymtl.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 8BC374BA2E1C Authentication-Results: sourceware.org; arc=none smtp.remote-ip=132.207.4.11 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1778208740; cv=none; b=tcaaboXHdQqMNd1IGJPGl7RX6baJmMs7BYIOM7aVgp5/GfTwhkMOYbnZs7GmCfseUKap95QDyyW1P1Dn6t8INXC8UPgYAlCZI/DUMzoxYqfGJAHlvJOf7PAgIFKKAhDwwK7BzpFuic0/Qhq//O493nSYOHiu0imKipdNx4wTbbc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1778208740; c=relaxed/simple; bh=2BXrFbVLBIETEZ8GsfbWekeMbDJVPIvl+M1O/fcoTzE=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=sJxko71m+xISA72QZplXNo+vkv1mrx/z2tw6NNaYRZFBFoykk4y7jgfmoOC8bgA9jAACixtgP2GESLwISyYjp68w+0sDtJcLH1W0LyGAfz57aHX2SR5g6J7vhCEm9FW0uysEz9xTepdArUT0vGgf/WkzdsvClYu8qQRRo6XDbnM= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=polymtl.ca header.i=@polymtl.ca header.a=rsa-sha256 header.s=oct2025 header.b=mywVrOJy DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8BC374BA2E1C 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 6482qEXN139340 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 7 May 2026 22:52:18 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 6482qEXN139340 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=oct2025; t=1778208739; bh=i42WesWez5kMYWRzVc0s5R+tUvGYYw0JrWzAC5YbaAw=; h=Date:Subject:To:Cc:From:In-Reply-To:From; b=mywVrOJy0+HG8RT0+VtLBv6NZZSut4Le+QSQFqVRn5SHL8kmA6UqP+K9uzRl0lO5I OREGPo6oAiY6OhGdkjRLZcO3SdaalYSzZidgcA68uQ2mY9lAwACKc5caeCxMwl2JIc 10Dq0D69gA8NdT8bjsYbyq+jR1ZYAmJ2JUHO9hPHr9MS0WZKXHjG7hPekRHp5K9B2P tbgyeeWJ5n5Z73uJtbZS+aDZkQAMzVf00mr2TeGoriSKncQ8nJRXo5+anYeEHicvqR PneCnxnthge8Ka7HXTPPzNtX9lgn2ei7P0uIrXbMtiO0u2qUFQo1avpuit5xgD6Av3 gU3v2o70Drwpw== Received: by simark.ca (Postfix) id D623A1E093; Thu, 07 May 2026 22:52:12 -0400 (EDT) Message-ID: <5b5fc6b8-a0b4-4346-88e1-4974a9eed31c@polymtl.ca> Date: Thu, 7 May 2026 22:52:12 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 11/11] gdb: multiple solib_ops per program space To: Tom Tromey , Simon Marchi Cc: gdb-patches@sourceware.org References: <20251209193610.296085-1-simon.marchi@efficios.com> <20251209193610.296085-12-simon.marchi@efficios.com> <87fr4fknaz.fsf@tromey.com> Content-Language: fr From: Simon Marchi In-Reply-To: <87fr4fknaz.fsf@tromey.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Fri, 8 May 2026 02:52:14 +0000 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 4/28/26 1:27 PM, Tom Tromey wrote: >>>>>> "Simon" == Simon Marchi writes: > > Simon> This patch adds the possibility for a program space to have multiple > Simon> solib_ops. The motivation for this is to support ROCm (GPU) debugging > Simon> more cleanly. > > Simon> Currently, when debugging a ROCm program, in order to be able to list > Simon> device code objects (the equivalent of shared libraries but for the > Simon> GPU), we install an instance of rocm_solib_ops as the program space's > Simon> sole solib_ops. But in order to still be able to list host shared > Simon> libraries, the rocm_solib_ops wraps the previously installed solib_ops > Simon> (currently always an svr4_solib_ops instance) and forwards method calls > Simon> to it. > > From this description and the comment in progspace.h, I wonder if this > is a case where an inferior should have multiple program spaces. I never thought about that. The host and device do share a single virtual address space. This doesn't mean that both host and device can necessarily access each other's memory transparently, but the host stuff and the device stuff won't overlap. So perhaps that could indeed be modeled by one struct address_space bound to two struct program_space. I'll discuss that with my team. > However I don't really want to block the work that's already been done. Going to multiple solib ops is a big design change, so it if turns out that it's not the right one, it's better to know now. > Simon> struct solib_ops > Simon> { > Simon> - explicit solib_ops (program_space *pspace) > Simon> - : m_pspace (pspace) > Simon> + explicit solib_ops (program_space *pspace, bool handle_main_objfile) > Simon> + : m_pspace (pspace), m_handle_main_objfile (handle_main_objfile) > > No need for 'explicit' any more. Ack. Simon