From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from forward502c.mail.yandex.net (forward502c.mail.yandex.net [IPv6:2a02:6b8:c03:500:1:45:d181:d502]) by sourceware.org (Postfix) with ESMTPS id 4EDEF3858C83 for ; Wed, 12 Apr 2023 18:46:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4EDEF3858C83 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-60.sas.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-60.sas.yp-c.yandex.net [IPv6:2a02:6b8:c08:8212:0:640:cefe:0]) by forward502c.mail.yandex.net (Yandex) with ESMTP id 1A7E05F492; Wed, 12 Apr 2023 21:46:36 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-60.sas.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id Wkbq3U2BXSw0-JraiAEO0; Wed, 12 Apr 2023 21:46:35 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1681325195; bh=1lrpWiH46pEQOvLaC7//+mnwI7P6A2VNSnojJXzY1nk=; h=From:In-Reply-To:Cc:Date:References:To:Subject:Message-ID; b=s0RWl/PQU5wuJ0OTJ+CWMGfDuEQBmoqiSxA6hCyPwW7RXi1hzL3C41urTYuOKiLjo 06/yQR83ypeUuioDAGXUih5cdPefT6La3XoSySrd93DFIajUKe2mstFNPUbxoIo27o BDu1OcsXdIAfI4D0XRTtzEP+PJAm8QX4uqcnypKw= Authentication-Results: mail-nwsmtp-smtp-production-main-60.sas.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: Date: Wed, 12 Apr 2023 23:46:31 +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=-2.9 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? 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. > Whatever happens, this whole proposal is going to be rejected, over > and over, 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. If no one spells out the proper reason, then maybe. Is it that difficult to spell out the reason of a rejection? > For the sake of your time and that of the > folks who have been pulled into this discussion, I think it would > really, *really* be a good idea to go figure out how to solve your > practical problem without trying to put new functionality in libc. In fact, instead of spelling out the rejection reason, all discussions were revolving around solving my problem w/o modifying libc. Basically there are currently 2 variations of such solutions: 1. Intercept glibc's loader mmap()s on a syscall level and bind a non-trivial logic to them (Jonathon's proposal) 2. Implement the dynamic loader outside of glibc (Szabolcs's proposal, and also my own wish). I'd be happy to implement 2, but glibc doesn't have the hooks needed for external dynamic loader, and it doesn't even allow to use the statically-linked patched glibc as such a loader in a separate namespace. Which is why so far I haven't seen a viable proposal on solving my problem, and haven't seen a clear explanation why the change to glibc is going to be rejected even if the raised concerns are all addressed.