From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by sourceware.org (Postfix) with ESMTPS id A69E13858C5E for ; Wed, 12 Apr 2023 19:52:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A69E13858C5E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=owlfolio.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=owlfolio.org Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 26AE5320091D for ; Wed, 12 Apr 2023 15:52:32 -0400 (EDT) Received: from imap45 ([10.202.2.95]) by compute1.internal (MEProxy); Wed, 12 Apr 2023 15:52:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=owlfolio.org; h= cc:content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1681329151; x=1681415551; bh=ut+o1MQeMqKPhEIv27MhqZmnU19JLyfwwf1 +PeOTY8w=; b=a8+eRUJ9Cx9fcudJzh4lCuwTCaGXNF0RfwA56sNmEGzd6G8gZj4 K/yvoedc4hxnPm69aIiPV8UegzzlXVNBbwBjY93JJ1lmkIIweiRd1zZFm81a/ytG EGkDzH44YGbSI/20Qu+c/EUNG7/+ZdiFakdxh+pnOq4Td1jXesgZ3sxr9EK4+IJu dhgO+lWRe0PW3fP3hTVjV/rO7cdWrCtW2McytSCUm+oNULm7ITOqgjb3fyVVGvr9 0s12pP+xbTKSb2IqVsiyNUvBa5ultM/InoK3UyPKiGXHv1US88iA9rh5NP41u+TZ tLc71Wsv/3yuEzo4VbWY4oY7OQyVco9auaw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1681329151; x= 1681415551; bh=ut+o1MQeMqKPhEIv27MhqZmnU19JLyfwwf1+PeOTY8w=; b=U gij0JQ0koxbTz/llF8s9SdKoImY3vhG1pQUgI6k2ZcwVKLRHe0S0h+b6R7NoR8Ss a4vVSpHB3vWmbe84ivoOI5WVaJHiGjBFIVQcKV8SRxhp70XrcPHe03kAMENU2Uiq 6NT7CFhBGyhpnDqLuYbbf0RmMHOrVlGE4KyefyK8dEqnddnYg3RUMTosmHP+IZMd bwlAB+Hd8hsjG0Xai1D/zSQxVoRaHA5QoRyXS+ZNKtJHIY1npaL9PQQemeFBNd30 d7HGVxofGL9Gg4tu7rli+vfk2W/FNntN05ygOYZUwKog6m/6U03eZuEedDDMe54g POKtAhVgxvrwMVvB+m7HA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdekiedgudeggecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdgk rggtkhcuhggvihhnsggvrhhgfdcuoeiirggtkhesohiflhhfohhlihhordhorhhgqeenuc ggtffrrghtthgvrhhnpeffteffkeehfeevheduleekheeugfekjedtgfejvdefueeujeeg hfeuieeijeekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpeiirggtkhesohiflhhfohhlihhordhorhhg X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 49DDF272007B; Wed, 12 Apr 2023 15:52:31 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-334-g8c072af647-fm-20230330.001-g8c072af6 Mime-Version: 1.0 Message-Id: <5f6348eb-5a00-4d3a-ad16-d0c263ae4a3c@app.fastmail.com> In-Reply-To: References: <2f3a10fa-4f79-7f9a-6407-d227dbf31935@yandex.ru> <298b04a6-3055-b89b-59c1-4cfbe955848e@yandex.ru> <81749d04-8cdb-de0b-b88e-24347ed535ba@yandex.ru> <729710b5-6dae-d5f2-99ee-6923be5e627d@yandex.ru> <20230412182043.GI3298@brightrain.aerifal.cx> Date: Wed, 12 Apr 2023 15:52:02 -0400 From: "Zack Weinberg" To: "GNU libc development" Subject: Re: [PATCH v9 0/13] implement dlmem() function Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, Apr 12, 2023, at 2:46 PM, stsp via Libc-alpha wrote: > 12.04.2023 23:20, Rich Felker =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> On Wed, Apr 12, 2023 at 11:00:19PM +0500, stsp wrote: >>> 12.04.2023 22:23, stsp =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >>>> The same "lazy relocation" can even be applied to a regular >>>> dlopen(). >>> Of course it can't, as dlopen() is expected to call library ctors. >>> So only with an optional dlmem() flag such behavior should be >>> performed, in which case dlsetbase() should also do the final >>> relocation and ctors calling. >> Have you not realized yet how far outside any concept of "reasonable" >> this ever-expanding contract is? > > How can I realize that, if it was never explained? In fact, the only > API review was from Szabolcs, and he just pointed to 2 problems that > are seemingly solvable. This discussion keeps going in circles. You, Stas, think you aren't getting any explanation for why your API proposals are being rejected. Meanwhile, Szabolcs, Adhemerval, Carlos, Rich, etc. all think they ARE giving you explanations for why they don't like this API. Let me try to highlight specific issues from the feedback you've been getting. It appears to me that your *API* proposal -- not any details of its implementation, the API itself -- is unacceptable *BECAUSE*: * It introduces a callback from the dynamic loader into user code, that is to be run with an internal lock held. glibc does already have callbacks like that, but we do not want to introduce any more of them, period. * It assumes that the dynamic loader will always, in the future, operate by creating a large initial mapping and then modifying protection flags on it. * It assumes that it the dynamic loader is, and will always be, capable of taking a pointer to a block of memory -- no matter how it was originally allocated -- and then chopping its virtual memory map up to satisfy the requirements of the embedded ELF program header table, without breaking anything else. [On this specific note, I foresee someone trying to write a dynamic module into memory allocated with memalign() or even plain old malloc(); calling dlmem() on this is very likely to apply PROT_NONE to address ranges containing malloc metadata!] Carlos also gave you the specific feedback that he thinks an API structured around handing the dynamic loader a file descriptor, not a pointer, would be much more likely to be accepted. Your response to this was "dlmem() can optionally preserve the destination mapping, which is not possible by definition with any file-based API." I accept that _you_ think that, but I don't think it's true, myself. If your goal is to force a shared library to be loaded into memory with specific characteristics, I can think of at least two designs that ought to be able to achieve that goal while still starting from the same place as fdlopen(). For instance, maybe we could have an fdlopen variant that called callback functions instead of mmap() and mprotect(). Unlike your dlmem_premap_t, I think it ought to be possible to avoid doing those specific operations with any locks held. zw