From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from forward502a.mail.yandex.net (forward502a.mail.yandex.net [178.154.239.82]) by sourceware.org (Postfix) with ESMTPS id 8EA3B3858D28 for ; Fri, 31 Mar 2023 17:36:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8EA3B3858D28 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-49.vla.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-49.vla.yp-c.yandex.net [IPv6:2a02:6b8:c18:3487:0:640:5432:0]) by forward502a.mail.yandex.net (Yandex) with ESMTP id 3B3245E9C2; Fri, 31 Mar 2023 20:36:29 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-49.vla.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id PaO8VRGDceA0-v6JD2fH9; Fri, 31 Mar 2023 20:36:28 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1680284188; bh=YHCyzrDQL/g7wkL7SSUKoiXIvnvSPSkzmf+0I1wIquo=; h=In-Reply-To:From:Date:References:To:Subject:Message-ID; b=Hrd15aAz3nUFzJMp9Qid1r7X5YcawjfnC54GMwQT2cTOEzuXpmHlsWmC+Uo6feIjn 1RkB9MDQSM6OOeVuR0d/cMe9EfY8/ZbCzoTbDfenMiy2xS+CUAnViWRlTjVcinQIXU TG6B1lmtlIQ2YWcxBdBZUmOOE1K1aAvfWkL2olvU= Authentication-Results: mail-nwsmtp-smtp-production-main-49.vla.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: Date: Fri, 31 Mar 2023 22:36:23 +0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH v9 0/13] implement dlmem() function Content-Language: en-US To: Szabolcs Nagy , Adhemerval Zanella Netto , libc-alpha@sourceware.org, janderson@rice.edu, Carlos O'Donell , Rich Felker References: <20230318165110.3672749-1-stsp2@yandex.ru> <2f3a10fa-4f79-7f9a-6407-d227dbf31935@yandex.ru> From: stsp In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.2 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: Hi! 31.03.2023 22:12, Szabolcs Nagy пишет: > loading from special place and loading into special place > are different things. Thank you for the technical comment! Somehow that happened that this thread went into non-technical very quickly. :( > you gave an example of the former but then talk about the > latter. These are related. File-based mmaps leave you no chance of preserving the destination mapping, so for my needs I took the interface for which mmaps are not mandatory. And then: 1. It suits my use-case surprisingly well 2. It suits as a base block for implementing things like dlopen_with_offset(), which I was planning to present in a subsequent patch series. But given the fact that people stopped believing my impl even works, I am not so sure... > loading from special place can be solved by writing the > contents to a temp file and loading that. That will end up with the casual mmaps(), so loading to special place won't be achieved as the result. > loading into special place is difficult especially if you > want to control the details of segment mapping. Its difficult. But my patch accumulated months of a work, so its just here. > in case of > your dlmem design it passes down a user callback that runs > under dynamic linker locks to map segments. the interface > contract of this callback is not documented, so it can > deadlock Good point. But this is a documentation issue, right? Not too much is needed: in the simple case you only do anonymous mmap() in a callback. In a more difficult case (my use-case) I do shm_open(), ftruncate() and mmap(). Of course I need to document that any libdl functions are disallowed, is this correct? > and exposes dynamic linker internals (makes > implementation changes harder later). Could you please clarify that part? typedef void * (dlmem_premap_t) (void *mappref, size_t maplength, size_t mapalign,               void *cookie); This only passes things needed for an initial mmap(). The single mmap() that just defines the mapping address. What internals do you mean? Also please note that the callback is optional and is not needed for 99% of the interesting cases possible with dlmem(). > if all you want is force mapping below 4G then you should > have asked for an RTLD_ flag (which may not be useful > enough or may not be supportable on all relevant targets, > but at least does not need significant loader changes). There is already such flag. Unfortunately my setup is much more complicated than that: I need to force the mapping under 4Gb AND I need to force it into the shared buffer which I then mmap() to another address... Yes, this may sound weird, and I am not sure if you want to read my entire discussion with Jonathon on why is that needed. But he did a good small summary here: https://sourceware.org/bugzilla/show_bug.cgi?id=30007#c8 Yes, its a technically difficult topic. Yes, we spent months on only me explaining my use-case! But why it suddenly downgraded to flames, is a bit unclear.