From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-3.4 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS,URIBL_BLACK shortcircuit=no autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id A063E1F5AE for ; Tue, 4 May 2021 12:59:34 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 31219398B413; Tue, 4 May 2021 12:59:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 31219398B413 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1620133151; bh=rYVHop8/KauJzsjgZJcEf2U4eFjhELxFjTGz9dgr9M4=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=KG/54ihZoC0d3r0DdEi6UnPtRMkd5CA3qtThOvyUWeWJmOLiyRFHkqUWFDW2ZjYcf uxsV9U/NOByfU216QJEzLXQIsaeOW95yrXm52/JQA79aBqA8dXsctSd/WZUkp8Xi26 RqpqgCzZx0aoHfIm3Jk/hyTtIrWYJgxa05+kYUgc= Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) by sourceware.org (Postfix) with ESMTPS id 368703959E50 for ; Tue, 4 May 2021 12:59:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 368703959E50 Received: by mail-qk1-x731.google.com with SMTP id 197so8051280qkl.12 for ; Tue, 04 May 2021 05:59:09 -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=rYVHop8/KauJzsjgZJcEf2U4eFjhELxFjTGz9dgr9M4=; b=pXZx9qGR+2pdWyuSdLMYL3fiwCo3+LHmmArMe2SO3YQZYuLpOTnUSSpRsCiJcQVrVF aZm5/Ffat9gbGgq8/JKDwMDnQE3O10jFqnvG4haVioRzZpnAAVI8J62H5d8LWlEFjeZe Whc5e0hfCCUghXacGQ+5FUX4aqnl99/Y0XPn0x6NtpF2wjyjuDplBLuN4CPmhI1SOu9A h5jXEs2PD3KcvmZkklaa8kylIimVhqVM8WhRCGUDwL9ocRtEKe+qbAYn8O+6rSNuEUAg /ebJDtXW+4i5ukph1DbfNaZVfmd0fDpH2rnq/KBRX5FYn5CL3+ruVreYR6cd66+sbC46 suNA== X-Gm-Message-State: AOAM5308O0xf8WB09j630GBDBIotb5DLRcOuQCK4Z1xP6Avye5gjmjSE 7hvGYKwCGwYUI+DOih42htOVBDL8vBuH+Q== X-Google-Smtp-Source: ABdhPJy26t1opzF/T7zmHV7U/W3a8r6r3pmRv05x3BiUVf/O/4/4yzaB/aiFxPAhZHkj59TkPhyaiA== X-Received: by 2002:a05:620a:6ce:: with SMTP id 14mr24664280qky.423.1620133148687; Tue, 04 May 2021 05:59:08 -0700 (PDT) Received: from [192.168.1.4] ([177.194.37.86]) by smtp.gmail.com with ESMTPSA id x19sm10792575qkx.107.2021.05.04.05.59.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 May 2021 05:59:08 -0700 (PDT) Subject: Re: [RFC] elf: Implement filtering of symbols historically defined in libpthread To: Florian Weimer , libc-alpha@sourceware.org, "H.J. Lu" References: <87h7jqguew.fsf@oldenburg.str.redhat.com> Message-ID: <3c32c2c4-3e94-25cb-7f15-4f8dda6a2324@linaro.org> Date: Tue, 4 May 2021 09:59:05 -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: <87h7jqguew.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Adhemerval Zanella via Libc-alpha Reply-To: Adhemerval Zanella Cc: Andreas Schwab Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On 28/04/2021 15:01, Florian Weimer via Libc-alpha wrote: > Definitions of these symbols in libc expose bugs in existing binaries > linked against earlier glibc versions. Therefore, hide these symbols > for old binaries. It is unfortunate that we didn't specify that redefine libc symbol visbility regarding elf linking should be considered undefined behaviour, so programs now rely un such behaviour (the bug foward compatibility is such a messy constraint...). It would be better if we knew earlier that a single thread API indication might just avoided this mess. In any case I don't see a better way than moving the logic to loader to handle such cases, the LD_PRELOAD is not really a solution. > > The symbol list in sysdeps/nptl/dl-pthread-weak.c contains some > symbols which have not been moved yet, but that is harmless because > the function is only invoked if the symbol is found in libc.so. > > The test suite passes on i686-gnu-linux, powerpc64-linux-gnu, > x86_64-linux-gnu with these changes. > > Is this the direction we want to go in? Then I'm going to add test > cases, probably using assembler. > > Personally I think it's not *too* bad, also not particularly nice > either. elf/dl-pthread-weak.os brings in 2-3 KiB of code (but few > run-time relocations). One possibility I have not mentioned in the > comment is to put the moved symbols into a GLIBCPTHREAD_2.34 symbol > version and use the presence of this version on the chain as an > indicator that the symbol uses special treatment. This eliminates the > separate string table. The downside is that we cannot easily add more > symbols if we discover some are missing. This happened to me during > development with pthread_mutexattr_gettype, which is a GLIBC_2.1 symbol > and therefore not actually suitable for detecting the presence of > libpthread (historically speaking). And it could happen again with > thrd_exit (which is of course much younger). My take on this is to postpone the 2.34 release until we have the libpthread/librt *fully* integrate on libc.so. The half way through only add unecessary complexity and it might avoid the 2-3 KiB binary increase in code .