From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x2f.google.com (mail-oa1-x2f.google.com [IPv6:2001:4860:4864:20::2f]) by sourceware.org (Postfix) with ESMTPS id 1CCCE3858D20 for ; Thu, 13 Apr 2023 18:09:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1CCCE3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-oa1-x2f.google.com with SMTP id 586e51a60fabf-187a742a963so57733fac.10 for ; Thu, 13 Apr 2023 11:09:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1681409379; x=1684001379; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=mBkogxr0bhnVUc8cqF4pSf/EXDniqxDOzLoIjmNfuI4=; b=s6Ngd0Uar1qrNDzgAGCRgY7CeFySWG6VeNlwMtYSpPSHoabYLkAkfvW3TBWqsaD2if EYmNGxp5qDykzFTsVXBibekd/oCyUlGmOF5O6v7au96E+zeI9dzdvfuCBQXGLoJYYYC7 uTIEoFJa8Q8h83COV/kuQMvoChj1yy3tmYqPPK/F+uHqCvtrgGDU/5vbJEx/pThSbiX6 FrIPYdnYNdk7llXqgyS7zdB+kpt7J2SlsOrxiBeS8hA9ofWXqB5wUBMay2HplZgza3It vXXP98SZePxeMGrOMp4PpkfM6j/IQ+FIQ58Uo4J5Wi8VvFRGCYgCMA3FhYXlTGEQ6C6Q GiQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681409379; x=1684001379; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=mBkogxr0bhnVUc8cqF4pSf/EXDniqxDOzLoIjmNfuI4=; b=Fi1RxTVBHjnZ8+fAIcCJ4+wWlJKnI73JSIotpNH0HJ9tDQ0idB9WEiMdxHMeib53IS auONsGfeDltYNgNUjunpj5iP6qtodfcc1RN9P6wUqvK9IjhPEvqXQHJv6czQTlsR2r4f RgO7fsPW+N5Ol1A/eK/xCL+yoo76+XZk1eRlp8Vp8cZs/pZ/R14SnR8AOqJmOs2qEK/l 1GP+96lbt01KFAif3oDMQy8XfcpESkfGTsb/MhM/egKYUo76zjKweKUICeJOkp11Dooy g7xVSu4pY7QQOnU+H/MkkvmTaH3PQRxYpUZ/cesNGQImv+hqtrpDygRbpScm4UFII0DN zB1A== X-Gm-Message-State: AAQBX9dMSdW4gUlvu2fqQ6p2akqIK10kuXaw0Et1Kbzq1D3AXd0wf8Cn A6gXBoyalbs2Shp3GuPrtVduKA6W/CjbY3Dx/WR5mA== X-Google-Smtp-Source: AKy350ZwBsmOJrymbOJ1TkFpua6fZFKrz9LCHFWH1/WDkIEzveUhLWG6BV1WkdsQzBYapCJe2gDtJg== X-Received: by 2002:a05:6870:e2cf:b0:187:a09f:a414 with SMTP id w15-20020a056870e2cf00b00187a09fa414mr734753oad.48.1681409379473; Thu, 13 Apr 2023 11:09:39 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c2:55a1:24f5:87d:bc38:ae5e? ([2804:1b3:a7c2:55a1:24f5:87d:bc38:ae5e]) by smtp.gmail.com with ESMTPSA id p14-20020a4a95ce000000b0053e8336f5dcsm856586ooi.7.2023.04.13.11.09.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Apr 2023 11:09:38 -0700 (PDT) Message-ID: <83ee7b42-7a50-e8d1-e9ca-58ec2a12a995@linaro.org> Date: Thu, 13 Apr 2023 15:09:35 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: [PATCH v9 0/13] implement dlmem() function Content-Language: en-US To: stsp , Szabolcs Nagy , Rich Felker Cc: libc-alpha@sourceware.org, janderson@rice.edu, Carlos O'Donell References: <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> <08d9ca95-112c-d85e-8e82-7a595ef4d051@yandex.ru> <78b5b5dc-5657-4bf8-24c6-6c00afb1cc40@yandex.ru> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <78b5b5dc-5657-4bf8-24c6-6c00afb1cc40@yandex.ru> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,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: On 13/04/23 12:59, stsp wrote: > >> you are adding a new interface without gathering consensus >> that it's a good idea at all or how it should work. > > I can get such a consensus only if people, > like you do (many thanks for that!), explain > the problems to me and suggest an amendments. > Unfortunately, its not the case. People are > saying that my proposal is bad, and the only > suggested amendment is to drop it immediately. :) > > But I am very thankful to those who at least did > some side-activities for me, like discussing my > use-case and reviewing part of the patches. > These activities were very valuable, but the real > problems were never discussed before, proposed > API was not reviewed, and so on. It is being tiring to work with your proposal because Rich already brought the inherent issue of exposing the loader internals for ELF objects [1] about 10 years ago, Szabolcs and myself are constantly trying to say that is not good libc interface (regardless it solved your specific problem), and even Jonathan tried to explore different alternatives. The main problem is no one from glibc is comfortable, including myself, to maintain and work with this interface. I don't want to maintain another interface with a lot of corner cases. Also the way approaching the glibc community, by not listening to criticism and ignoring multiple remarks; saying that you have addresses the comments without any ack; or flooding the maillist with multiple version without addressing previous feedback is really, and I want to stress the really here, tiring. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=11767 > > And with your input I already advanced to the > point where the API can be split into 2 parts, > whereas before I thought of dlmem() as a > thing in itself that can't be split. Now I see > that RTLD_NORELOC can solve the biggest part > of the puzzle alone. Sigh, I really would like to say this is less rude manner but I will be succinct so you and others can avoid waste time in this manner. The "dlopen of in-memory ET_DYN or ET_EXEC object" is a *NACK* from me, even if is split in multiple APIs. Myself, Szabolsh, and Rich already explained, but you seemed resolute to not accept it. A fdlopen or even a dlopen_with_offset could make sense, FreeBSD at least has fdlopen so it is a precedent of a realworld case. > > >> when i said you should write your own loader i expected >> you to create simple stubs in memory at the location >> you want them to be and bind them to a library that >> is loaded by libc (so you can connect your weird world >> with the libc world). >> >> it looked like a simple solution to me, but i still dont >> know exactly your requirements so in a sense we still >> don't have a well understood use-case for any of your >> proposed changes. so maye the use-case is where you >> should start. > You mean "restart". :) > As I already explained it very thoroughly in the > bugzilla, but you missed that and now its better > to repeat, since the bugzilla entry had a very > lengthy discussions afterwards. > > The use-case is a VM with 32bit code inside. > It has a 4Gb window mapped somewhere in > a 64bit space (call it VM_window_start). > The task is very simple: first I find the suitable > mapping address within a VM address space. > Such address is within the 0-4Gb boundaries. > I relocate the solib to that "low" address. > Unfortunately this is still not visible to the VM, > because VM's window is at VM_window_start, > as we remember. So in order for VM-running > 32bit code to access the solib's data (like .bss, > .rodata) when it gets a 32bit pointer to such > data, I also need to map the full duplicate of > the solib object into the address that looks like: > > dupe_addr = VM_window_start + reloc_addr > > For that I invented the optional dlmem flag > that doesn't destroy the destination mapping. > But such flag doesn't survive your requirement > to get rid of a call-back, so in the next prop > I'll pass a shm fd to dlmem instead, and an > optional flag will ask dlmem() to mmap that > fd as a destination backing-store. > > So I am sure all problems can be solved! > But of course I can't do that alone, if everyone > just keeps saying "drop your patches immediately".