From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from forward501c.mail.yandex.net (forward501c.mail.yandex.net [IPv6:2a02:6b8:c03:500:1:45:d181:d501]) by sourceware.org (Postfix) with ESMTPS id 798343858436 for ; Wed, 29 Mar 2023 13:10:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 798343858436 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-33.iva.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-33.iva.yp-c.yandex.net [IPv6:2a02:6b8:c0c:2016:0:640:1006:0]) by forward501c.mail.yandex.net (Yandex) with ESMTP id 5EFEE5F574; Wed, 29 Mar 2023 16:10:15 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-33.iva.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id BAIsMa2Wp0U0-h3UbqrZg; Wed, 29 Mar 2023 16:10:14 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1680095414; bh=dPb0dFewbALqPDY+aOinJEIA3aKdyY2FAdhwhS1O8ZE=; h=In-Reply-To:From:Date:References:To:Subject:Message-ID; b=LW9WGQactlwpUCljj312uHxctmEO2uBGhrE8wI6XZ77lTXP2vMhFn4wengNNC63M/ gHmcGF7VNrJxykAnnyrJ/VVw54UKiy3HB0uf9Rcvj9S7JnNz04buUUTWRRiEuu2ARI e//fR7H1L8nKk8SzHkvIstGjYcPfWf6zjRfIfkJg= Authentication-Results: mail-nwsmtp-smtp-production-main-33.iva.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: Date: Wed, 29 Mar 2023 18:10:11 +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: Adhemerval Zanella Netto , libc-alpha@sourceware.org, janderson@rice.edu, Carlos O'Donell , Rich Felker References: <20230318165110.3672749-1-stsp2@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.7 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,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: Hi Adhemerval, thanks for a follow-up! 29.03.2023 17:32, Adhemerval Zanella Netto пишет: > This discussion has been dragging without much conclusion while you > have sent > multiple iterations of the same proposal without addressing the initial issues > Carlos, Jonathan, and myself have raised. > > I will not focus on your specific usercase since it is quite singular and I > think will not be applicable to a libc interface (mapping a VM memory with > different bit size and gluing all together should be an application domain > instead of bleeding out the interface to the libc). Yes, which is why I am trying to put in the "widely" requested in the past dlmem() function, which is quite agnostic to my use-case but allows me to accomplish the task. > Jonathan already summarized the main issue with dlmem: > > - dlmem() seems to to expect the user to parse the program headers and mmap() > the binary as required. That requires the application to re-implement a core, > delicate piece of ld.so... and do so correctly. From an API design perspective, > that seems like a very poor choice of abstraction. > > As well Carlos: > > * No guarantee that the memory that is loaded meets the preconditions for the > dynamic loader and application uses. > > And this alone seems to me that this interface is not easily composable and OK, yes, I've heard all of you, but what should I do? I can SWEAR that my test-cases do not parse the elf headers. I can swear that I have no idea what are you talking about. Well, I did that already, but nothing helps. :( So how should I proceed with the claim that was said by everyone, and yet never confirmed by a single fact? I do not parse any elf headers, maybe glibc does, I do not! If this is wrong, please point me IN MY TEST-CASES that I actually do this. > adds a lot of corner cases if the user does not provide an expected ELF image. > This is in par of what Carlos has raised [1] and IMHO you have not addresses the > issues, since you have focused on how this interface applies to your specific > problem instead of see who it fits as a generic libc interface (I will let > Carlos comment further). I have not addressed that issue, I have not seen that issue, I don't believe this issue even exist. What should I do? Please, be constructive. You can point it to me IF it is there. > So I don't think dlmem really fits on glibc, although I might take a loot > on the internal code refactoring. I am ccing Rich Felker, creator of musl > libc, since he might have some additional insights whether this interface > make sense or not (and he usually have good ones). Thanks! I appreciate the involvement of Rich Felker, or any other activity to bring that discussion further. But we need to get off the aforementioned question around the elf headers. Also please note that I have a v10 locally with some fixes and new test-cases, so v9 should not be reviewed quite literally.