From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from forward501a.mail.yandex.net (forward501a.mail.yandex.net [178.154.239.81]) by sourceware.org (Postfix) with ESMTPS id 72CF23858D35 for ; Thu, 13 Apr 2023 10:01:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 72CF23858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=yandex.ru Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=yandex.ru Received: from mail-nwsmtp-smtp-production-main-81.vla.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-81.vla.yp-c.yandex.net [IPv6:2a02:6b8:c1d:63cd:0:640:4ab5:0]) by forward501a.mail.yandex.net (Yandex) with ESMTP id 826445F192; Thu, 13 Apr 2023 13:01:54 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-81.vla.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id p1UATd0q6eA0-rFynAh94; Thu, 13 Apr 2023 13:01:53 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1681380114; bh=J3pGb4xqsvA0skwq/sXmwhDIfgDE566LHglwhd0EdN8=; h=From:In-Reply-To:Cc:Date:References:To:Subject:Message-ID; b=DJ7m9JhnYH+vZ7hkNpwdLkoUD/HC6n4iOzlx3Prc0YACmECOBNifhS+NDfjMt6Ei6 iTum9+UjA1WfCobWuT2Qi2sKZHQE4jbSYiqspSJ9B7IRqvSSg6QJcXzNgQFDKLzQYG 098zHeTYW6PgYb7LnrFe1B0349FzLOykI4xHkzn4= Authentication-Results: mail-nwsmtp-smtp-production-main-81.vla.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <08d9ca95-112c-d85e-8e82-7a595ef4d051@yandex.ru> Date: Thu, 13 Apr 2023 15:01:50 +0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: [PATCH v9 0/13] implement dlmem() function Content-Language: en-US To: Rich Felker Cc: Szabolcs Nagy , Adhemerval Zanella Netto , libc-alpha@sourceware.org, janderson@rice.edu, Carlos O'Donell 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> From: stsp In-Reply-To: <20230412182043.GI3298@brightrain.aerifal.cx> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,NICE_REPLY_A,SPF_HELO_NONE,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: 12.04.2023 23:20, Rich Felker пишет: > On Wed, Apr 12, 2023 at 11:00:19PM +0500, stsp wrote: >> 12.04.2023 22:23, stsp пишет: >>> 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? OK, consider this small proposal (not dlmem): RTLD_NORELOC - new flag to skip the relocation step. dlrelocate(handle, base) - new call to explicitly perform the relocation (and call ctors) that was skipped with RTLD_NORELOC flag. That alone already solves most of what I wanted to achieve with dlmem(). Namely, it allows the user to specify the relocation address he needs. He does so by manually moving the solib image to the desired location, and then calling dlrelocate() with new base address. Could you please tell me beforehand why that proposal will be rejected? > Whatever happens, this whole proposal is going to be rejected, over > and over, I believe you, but the question is still "why". In all the other projects I contributed in, the proposals were in most cases getting the change requests. And in glibc, the only available change request is to drop the proposal? :) > and the more effort you pour into engineering it on the > belief that it will somehow eventually be accepted, the more > disappointed (and maybe angry?) you're going to be at the people who > have to keep rejecting it. This is a wrong assumption, because in a worst case this code will make it into a standalone loader. So far I know how to do that only until glibc changes one of its core structs, like rtld_global_ro or link_map. With every such change, the loader will stop working. So that would be a very unfortunate and unreliable solution. I'd like to avoid it, but there is no risk that my efforts working on that code will be wasted.