From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) by sourceware.org (Postfix) with ESMTPS id E3D533858D20 for ; Thu, 13 Apr 2023 20:02:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E3D533858D20 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-oi1-x235.google.com with SMTP id ec6so3996744oib.8 for ; Thu, 13 Apr 2023 13:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1681416139; x=1684008139; 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=l879oUjt3sPbsWeqWZaj3hR4kWSdsgT7G0xi5fCPb/k=; b=iQ+PisVA1W5qbuA0SGnXgo3TAFfbESyLiwHbqG/DhvVCAgp0Vunu1w9acMpm31/451 oATeZaMRVlOBHdPrvfzXwU7cJyoU8+ec7JUmgfX96efnrNg8fFBELvjhuNZrc9ekHCQk +K1/gN7UO2DCUD1TXH0ZR427qey4beeW72f2wooEBalvCnkYyUE5ZaBV3zWhth9ODRQH kXdeb3iDQNrEKYqNMDt77/BgGWXHOEILnWNbzywETtob1+kaExhA9y/JXi4sroScnptJ +W9v833qp/A0Bkowo4k6wixXrh8P47hDwzzD6dkAnBSpYAT6J4MpPQURfxLsjWRTLbot 1ehg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681416139; x=1684008139; 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=l879oUjt3sPbsWeqWZaj3hR4kWSdsgT7G0xi5fCPb/k=; b=ZjbGBN4b5Tk1dScyGLCd1BYJWhvPo3sDEQNaoK8ib7lxFhodfLOGReM3EQis3TYG7J YEky4ygyBE3caAXAgYViROXUomq/MYOayLHCTvkWl0DTf1yNbYxF/WjyBX5wGRp0D0d/ VoVuV4a3ndjaoScX5acOroP/V48fA5qlBvqnbULm8iYmny3fpncgc3Xujj+Z2r+Imb26 +p55WJMYBM9SQ+YBk/i60UXNO6FZOWmMPH3NUdiRWwW7Fu5MKWGW/5/cq6YWXj1cQolT b4/r1Vz1WuVMIHAUb4q2SuGAXJIRkO7l2z/jTwgKSABt/0m+LeWBZYyXnuNaJQoBFz9m 5V6g== X-Gm-Message-State: AAQBX9eGz8zxGYeEcu2vyOf3sA5Le7R66V2AeUj3cGQrqy2ZePb/dtnm HpEjTfDOnnuQQPW1pkDJVOw4xQ== X-Google-Smtp-Source: AKy350a75yF5QMNZ0kvrEJHa9rdn3kNAAxTJTqQJih1mC2io+goctwPk7iPk4dmb5nlsVfRPRP7skQ== X-Received: by 2002:a54:4117:0:b0:38b:2ac9:9f9b with SMTP id l23-20020a544117000000b0038b2ac99f9bmr1499496oic.47.1681416139125; Thu, 13 Apr 2023 13:02:19 -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 j21-20020a056808057500b00383b371f2a7sm978196oig.42.2023.04.13.13.02.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Apr 2023 13:02:18 -0700 (PDT) Message-ID: <52d0b5e8-2c81-66e6-60dc-771d01b26fd6@linaro.org> Date: Thu, 13 Apr 2023 17:02:14 -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> <83ee7b42-7a50-e8d1-e9ca-58ec2a12a995@linaro.org> <59862084-0fe3-7642-d3b3-01bb87eef7db@yandex.ru> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,BODY_8BITS,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 16:29, stsp wrote: > 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? Because it is the same remark bought *multiple* times in this thread [1] that you keep saying it is not important on the discussion: "It would be possible to require the caller to arrange all of these things, but that's basically offloading A LOT of the ELF loading process onto the calling program and I don't think that makes for a reasonable public interface for glibc to provide." And every time someone brought it [2], you just reply that this since it does not fit in your usercase this is not an acceptable solution. And then we kept in circles, with multiple developers saying that this interface-like is not reasonable, and you saying that it is the only way to solve your specific usercase. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=11767#c16 [2] https://sourceware.org/pipermail/libc-alpha/2023-April/146886.html > > >>    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. You can just use glibc, apply your patches, and use it instead. > >>> 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. Because every time someone bring the corner cases you just dismiss saying that either the person does not understand you [1] and it is up to review prove you are wrong; or you dismiss saying that the remarks are not applicable. [3] https://sourceware.org/pipermail/libc-alpha/2023-March/146729.html [4] https://sourceware.org/pipermail/libc-alpha/2023-March/146717.html > > >> 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. Because we are not moving anywhere, if you have not already get it the replies are to try to show you the problems with the RFE proposal, not to move toward having dlmem-like interface incorporated.