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 998A13858D28 for ; Tue, 15 Mar 2022 12:07:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 998A13858D28 Received: by mail-oi1-x235.google.com with SMTP id j83so20563959oih.6 for ; Tue, 15 Mar 2022 05:07:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=YAgdoiRPSJfX/EDt7+LYKETqvwallGPaQXygpdsVM2g=; b=yGr0ZqV5XfFe0RXGPH2KN53r+rgsWvkGSb55vfCEJ1raOO7RL/nhoZxufjSMENu+PH nZ19GDNwl0h5/RuQb4/wvgGDHnNyQUCWzNPpa+ujVb9dPqEmCOEZbN+PnSpBEA657OIs wh9AlZJs60XEXd+UwTS4cvwMZtqK4N7/vFOSiYuoK2wPR2uCe9n8L0zDrQJTWtU9SMwj 2ACebl8LDuNunsiwmgtwf9S8vhGh5UnO2oDKpRpCaOsROyW4mTqjaGYmzsQzAmbF9HrR gxC8vj9ws2hBR+dW/VXOOA+1Nwv6jV6BfIEpocmtY/i9fL0gIoC5q2yPUATx/VtdHLjj 2jIA== X-Gm-Message-State: AOAM533V3fos6WQ83NRVCQBwGEFqQh1jBTIvfONvrvkPQlKkLOVIRMv6 2wvulu6HFELgqWz+DW2SUTriVA== X-Google-Smtp-Source: ABdhPJyR1qZru78x4Fbnj9AO3UHqyw7TnsYGwE8ErfGp4QQcsJ2OuKLWvt3RwU454qEE5LlZv+WUjQ== X-Received: by 2002:a05:6808:15a2:b0:2d9:df7f:e6f2 with SMTP id t34-20020a05680815a200b002d9df7fe6f2mr1587270oiw.94.1647346024746; Tue, 15 Mar 2022 05:07:04 -0700 (PDT) Received: from ?IPV6:2804:431:c7ca:99a3:45da:fbd7:8ab4:7823? ([2804:431:c7ca:99a3:45da:fbd7:8ab4:7823]) by smtp.gmail.com with ESMTPSA id w8-20020a056830410800b005b25e8430basm9097645ott.6.2022.03.15.05.07.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Mar 2022 05:07:04 -0700 (PDT) Message-ID: <07c60a94-76b5-4db3-3832-c1ad5aff0487@linaro.org> Date: Tue, 15 Mar 2022 09:07:01 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: The case for statically linked libc/pthread Content-Language: en-US To: "Soni L." , Libc-help References: <5e390a65-bcfc-5924-cd49-39222d640165@gmail.com> From: Adhemerval Zanella In-Reply-To: <5e390a65-bcfc-5924-cd49-39222d640165@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.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, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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, 15 Mar 2022 12:07:07 -0000 On 27/02/2022 16:57, Soni L. via Libc-help wrote: > It'd be nice if the kernel could keep track of which code segments > allocated memory or spawned threads, so that dlclose can release those > resources. In fact this is particularly important for correctness in > dlclose. But that requires libc to be statically linked in the first place. > > There's no hope for dlclose without statically linked libc. Although deprecated, glibc still supports dlopen for static binaries so it won't help you much. AFAIU the idea is eventually make no-op on static build. For dynamic linker binaries, a kernel interface would probably introduce a large slow down on munmap (another interface to check if pointer is used might introduce ABA issues): kernel will need to stop the process and check N mmap against M threads (so the naive implementation will be O(n*m), maybe with some clever data structure it could be lowered). So I think it high unlikely that kernel will ever provide such interface, no for POSIX like kernel like Linux. Another option would be to make dlclose always a nop, for static and dynamic, as musl does. However some users do expect that dlclose unmap the memory segments and the library is reinitialized (run constructors, init functions, etc) [1] [2]. In any case I think it is a fair assumption with current API that synchronization should be done by the program. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=16805 [2] https://sourceware.org/bugzilla/show_bug.cgi?id=28877