From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) by sourceware.org (Postfix) with ESMTPS id 557473983838 for ; Tue, 8 Jun 2021 19:25:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 557473983838 Received: by mail-qt1-x82e.google.com with SMTP id p21so4423484qtw.6 for ; Tue, 08 Jun 2021 12:25:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=CdlR+zn/i8Okav2/1UQtBYjhguLw6ZB9DMcbdoLDKZQ=; b=NGcXQfYnRbjbVuH0HRMtGa++DtJRNnil5k9qFijLbkePqnX64P8Lq9rR/n4nwQAwqa mSDNyp6qpHPGZ0/Mrw/aBIHz+bCIOjXPtkz5OWrn7k6+7ALsRWfrDAhfQyNmAB4vymGN YMnXnFdjMoBL9PGNkBwxJVlSNXJ9XbaQM528Uom2GfIAoZFjkB9hdMy3di8g4cMmqnbm rpvlq2zqPHY6dv+fy8WF77KDR1D8ljhIWdHIPwiLMsY2bLWSqc9Za03m1fGQ8P7On55M yK3IlKNneVSXfO5AQHIl9PIYiwKNvcXWA0WTHnKpjm8D6NOr6PECmE3J/3uKhoYwCRKU JJCQ== X-Gm-Message-State: AOAM531PkdFycBOv6JRvLp724dNWOkeZwyLWs9fdNjIO1leKNMVzX2Uo LdIMcjMfnF0zIs8TN842EExMXOMtT3NdEQ== X-Google-Smtp-Source: ABdhPJzu1ocbVZ0EBzDXQLOu9a1NeFXQokM5pSO+OMNi66BNs8Jtqlb+K4Klm/lcfeEziupnv0e2ZA== X-Received: by 2002:ac8:5241:: with SMTP id y1mr23206655qtn.188.1623180333692; Tue, 08 Jun 2021 12:25:33 -0700 (PDT) Received: from [192.168.1.4] ([177.194.59.218]) by smtp.gmail.com with ESMTPSA id t187sm12408061qkc.56.2021.06.08.12.25.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Jun 2021 12:25:33 -0700 (PDT) Subject: Re: inode-based dlopen caching To: Florian Weimer , "Soni L." Cc: Libc-help References: <87zgw09tww.fsf@oldenburg.str.redhat.com> <0242da65-0563-d03d-2ba7-5318c2a6c010@linaro.org> <87r1hc9ssx.fsf@oldenburg.str.redhat.com> <87czsw9q6o.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Message-ID: Date: Tue, 8 Jun 2021 16:25:29 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <87czsw9q6o.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.4 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.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 19:25:44 -0000 On 08/06/2021 15:17, Florian Weimer wrote: > * Soni L.: > >> The motivating use-case is hexchat plugins. Especially when they're >> written in Rust. Rust is supposed to provide memory safety but some >> edge-cases with dlopen break that, like truncating the shared library, >> or closing a shared library that has spawned threads. > > Truncating the shared object will always cause problems until the kernel > implements MAP_COPY, or we stop mapping code in the dynamic loader. Which I recall some discussion from Linus won't going to happen (unless he changed his mind, the discussion it some years old already). > > Another option (implemented by GHC and others) is to have a customer > loader. Except for initial-exec memory and symbol interposition, there > is nothing magic at all about dlopen. Applications certainly can > implement their own object code loading mechanisms. I think the main problem is implement all the ELF idiosyncrasies correctly, assuming that ELF is used in first place.