From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id x8r3MN2nf2hrtTkAWB0awg (envelope-from ) for ; Tue, 22 Jul 2025 11:01:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1753196509; bh=X1nQpe4hfv0BGUnp30mpMeDaz/YFIDLDBvJjh8SVGM8=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=nK7haS+c6ngzUYGKAv9DRDWi+hEJahTWQRx4wkgnIA1Q5CO1tJQM1iKI2HTEiC2po gMLOmnfK2UAHWff+6jV2cJcMIfrcxbgM+7uZjwGT9IdHhAaKuSCC8Z1UyMvuzz6/WY hR8irGBVQBaXz/jC/vbw+fqqeB6A3zKg/6dUa1as= Received: by simark.ca (Postfix, from userid 112) id B30741E11C; Tue, 22 Jul 2025 11:01:49 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-9.1 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,RCVD_IN_VALIDITY_RPBL, RCVD_IN_VALIDITY_SAFE autolearn=unavailable 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=mYHujCzy; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=fcgX8qg9; dkim-atps=neutral Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (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 208531E089 for ; Tue, 22 Jul 2025 11:01:49 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8202D3858C54 for ; Tue, 22 Jul 2025 15:01:48 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8202D3858C54 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=mYHujCzy; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=fcgX8qg9 Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 93FAF3858CD1 for ; Tue, 22 Jul 2025 14:58:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 93FAF3858CD1 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 93FAF3858CD1 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=1753196334; cv=none; b=jHe6h20Re+ES9Xi/fCLLl+2S0xkOPI9n26li6gIb4p7t0v62R0Qd/qph2GY80q4BHfq7TEp+bTSEvtIOJ8W+j0XXNrzYxUY7jzfSb27f9OrUGPh+VHLHeWaa+x+m074D7j3gQYywPepp06FUkHBaLZxu5PJvUtRMcs8aYYRF0fs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1753196334; c=relaxed/simple; bh=X1nQpe4hfv0BGUnp30mpMeDaz/YFIDLDBvJjh8SVGM8=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:To:From; b=NbdU6yULndS74E2S6PwP4qZq5a2CBfc60jsOahXuNTP9DIT6AwwIbvL1e8cVIrZEE5f8zmSzv3afgv9sWaqet7OYkB75EWN2a3q7qP8u7yy25yctoTD/BEqsF/E1/9poItHKUsV2nhVPelqIAWPXHyYxfdDuRv5txP9Xq68zJoI= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 93FAF3858CD1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1753196333; bh=X1nQpe4hfv0BGUnp30mpMeDaz/YFIDLDBvJjh8SVGM8=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=mYHujCzy3uksu6ddnqYhpVN2tVZB48OAFbTounHrk6Ww0hqwEbpdZZ2098ag3ToBF PXLoz7nrdQm6+s1OwVpgeiU+KiYRkLOo+c4UTLnPn8qXiLOJTD/b0mfmzkOa7i2ZmE Ed227MqAh5sBUrCkWzpOC53NFHAOpApvUTT05W9s= Received: by simark.ca (Postfix, from userid 112) id 8A61D1E11E; Tue, 22 Jul 2025 10:58:53 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1753196332; bh=X1nQpe4hfv0BGUnp30mpMeDaz/YFIDLDBvJjh8SVGM8=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=fcgX8qg9kPGsZUlFzO+x6+x+4vr8rTpv1dDaPak1W9Pr7ZEsUqDkIBcgeJnT2mIaC YvAV0zvdqpr2zLWLntoETh4+OMBlMRfRxucy91dH4GjvxNJTcYi6unDDipRogEmR1x ddMyWkpMyZ/NpkG3N4HRCLNo+BoupKQ2A0ov3YAM= Received: from [172.16.0.192] (192-222-132-26.qc.cable.ebox.net [192.222.132.26]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 321E61E089; Tue, 22 Jul 2025 10:58:52 -0400 (EDT) Message-ID: <3bec817b-1660-44df-b20d-64b75e1726fa@simark.ca> Date: Tue, 22 Jul 2025 10:58:51 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 03/15] gdb, gdbserver: support dlmopen() To: "Metzger, Markus T" , "hjl.tools@gmail.com" Cc: "gdb-patches@sourceware.org" References: <20220602132514.957983-1-markus.t.metzger@intel.com> <20220602132514.957983-4-markus.t.metzger@intel.com> <2f5a89a5-95e0-44bb-aa47-755451dc0192@simark.ca> Content-Language: fr From: Simon Marchi 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 7/22/25 3:07 AM, Metzger, Markus T wrote: > Hello Simon, > > This concept of the debug object moving is much older. See for example: > > commit 60d09f0a0d8000359b8f1dd14b51e7f013ea9e5c > Author: Markus Metzger > Date: Fri Mar 11 06:46:15 2022 +0100 > > gdb, solib-svr4: remove locate_base() > > Whenever we call locate_base(), we clear info->debug_base directly before > the call. Thus, we never cache the base location as locate_base() had > intended. > > Move the svr4_have_link_map_offsets() check into elf_locate_base(), inline > locate_base() at all call sites, and remove it. > > > This patch removes some caching of the debug base that had been intentionally > disabled on every call to locate_base(), which was supposed to find the debug > object once and then cache its address for further use. > > A typical hunk in this patch is: > > @@ -1839,8 +1799,8 @@ svr4_handle_solib_event (void) > return; > > /* Always locate the debug struct, in case it moved. */ > - info->debug_base = 0; > - if (locate_base (info) == 0) > + info->debug_base = elf_locate_base (); > + if (info->debug_base == 0) > { > /* It's possible for the reloc_complete probe to be triggered before > the linker has set the DT_DEBUG pointer (for example, when the > > Maybe H.J. has more information on this; a concrete example, maybe? Thanks for the pointer to the patch. I understand how this code was indeed dead before your patch. If H.J. knows concrete examples, it would be very nice. The 2008 patch from Daniel Jacobowitz I pointed to in my other email [1], that I think started this pattern, which probably then spread by copy-paste, was about having a custom dynamic loader interposing itself between the kernel and the libc dynamic loader: They are motivated by a custom dynamic linker I've been working with for the last few weeks. It is an intermediate stage between the kernel ELF loader and the C library's normal runtime loader, which adjusts a couple of things in the new binary before it starts. I have made it as transparent to the debugger as possible, but there are still a few quirks that seem impossible to eliminate (they bump up against the userspace/kernelspace security boundary). My understanding is that his binary was using a custom dynamic loader (INTERP), which was doing some stuff, then handed control over to the real libc dynamic loader. My question is basically: do we need to support this use case? If this was to support an experiment that someone was doing 20 years ago and nothing else, then perhaps we can simplify the code today, which will then make subsequent changes easier. Right now I'm leaning towards not having to support that kind of use case, until proven otherwise. Simon [1] https://pi.simark.ca/gdb-patches/20080221014732.GA27568@caradoc.them.org/T/#mb8a42f0b940333583bb4f7fffc3ea71dd75180de