From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from forward501b.mail.yandex.net (forward501b.mail.yandex.net [178.154.239.145]) by sourceware.org (Postfix) with ESMTPS id 2152E3858D32 for ; Thu, 13 Apr 2023 19:29:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2152E3858D32 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-91.myt.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-91.myt.yp-c.yandex.net [IPv6:2a02:6b8:c12:24a7:0:640:a059:0]) by forward501b.mail.yandex.net (Yandex) with ESMTP id 858A05F23D; Thu, 13 Apr 2023 22:29:22 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-91.myt.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id JTdVS17s8mI0-w4ljUDtu; Thu, 13 Apr 2023 22:29:21 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1681414162; bh=B2gSbvOPvZIfzS7BiZuVTFoaN/Kxqzrep/qfUyXYcko=; h=From:In-Reply-To:Cc:Date:References:To:Subject:Message-ID; b=c8P9isg4QzcDCJ5ovh2ZVgw5e7F3hTx74Ut5tWGvh/X5F3bCrm9Swlhf9WJM49yCT wFfnBxRN/EYjjDwaPa7gtMk8YvpoVX5s66FU8QN16Lw/zYKZl6xTz4ekVgE8RVZ1sU ZcqHJ17r0bEANq71m4DLHmOGUGTbqdqIcPzREJIw= Authentication-Results: mail-nwsmtp-smtp-production-main-91.myt.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: Date: Fri, 14 Apr 2023 00:29:19 +0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH v9 0/13] implement dlmem() function Content-Language: en-US To: Adhemerval Zanella Netto , 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> <83ee7b42-7a50-e8d1-e9ca-58ec2a12a995@linaro.org> <59862084-0fe3-7642-d3b3-01bb87eef7db@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.8 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: Adhemerval, 14.04.2023 00:12, Adhemerval Zanella Netto пишет: >> I admit you probably couldn't do that initially, >> because I poorly documented my API. But >> when Carlos asked for a more detailed spec, >> I did. Now you can express your objections >> in a detailed manner, let me even attach >> the prev API draft to help you doing that. >> Of course this draft will be simplified a lot, >> but for such a "generic" objections please >> use its current form. > The problem is not a poor documented ABI, the ABI itself has inherent > corner cases brought multiple times. By whom? Where? You referred to some 10 years old thread, where I didn't even participated. Is it too much to ask to at least point me to a particular comment in that thread? > The problem you are trying to > solve would be better served with a custom loader. I wish to have a custom loader. But so far I don't know how to make it friendly to glibc. Custom loader needs to be able to create a link-map, and glibc currently doesn't have a hook to do that. I currently only know how to create a custom loader that works until glibc changes either struct link_map or struct rtld_global_ro. Such custom loader can be done, but it won't be very reliable. >> I have expressed the plans at removing all the >> corner cases that Szabolcs pointed to. If you >> point more, I'll definitely take an actions. >> Off-loading the biggest part to RTLD_NORELOC >> will reduce the proposal considerably, avoid >> the callback and most of other complexity, so >> why such a prejudice? Why can't we just discuss, >> amend, see what happens? > The RTLD_NORELOC itself is not a better approach, is just moving the > same corner cases that we brought to a different symbol... against > walking in cycles. Why not to show these problems? Szabolcs always does. You always assert on their existence, as if I have no right to even ask what they are. Maybe they are obvious, maybe I have to realize them w/o asking, but I can't, I am a novice. Please, pretty please, can you detail those problems? It would be best if you detail them with the reference to my drafts - then I'll immediately understand. > Do not bother, I think the best course of action is just to drop > the RFE. Why is that constructive? Well is not for Szabolcs, I could suspect its just me. But now if he points to the problems promptly, then I am sure its possible to do.