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: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-2.8 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RDNS_DYNAMIC,SPF_HELO_PASS,SPF_PASS,URIBL_BLACK shortcircuit=no autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (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 7F6BA1F5AE for ; Tue, 4 May 2021 11:48:19 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3405A396AC3D; Tue, 4 May 2021 11:48:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3405A396AC3D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1620128898; bh=sF+ISe0jZwvAUJzMmLLMppVvEqGDuJF1mjTQkj4kqEE=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=k5jNWVSAM2kCa3e1sXlovNBCt1sKtpVgCtQGBz1sdPLSi4m/AsvSzvNv9aZypkbUV 465v4F8T1agoNw5gc51XYpG4uYHFLQ8qDGukE/hxoTvilYLc5IAdWxZFtJzqIkYJ9D m/41rVGZtJ1eg3vdN0lwGQdH9/0dytAIdBA9R7nc= Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) by sourceware.org (Postfix) with ESMTPS id 7557B3958C2B for ; Tue, 4 May 2021 11:48:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7557B3958C2B Received: by mail-ot1-x32d.google.com with SMTP id g15-20020a9d128f0000b02902a7d7a7bb6eso1189018otg.9 for ; Tue, 04 May 2021 04:48:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sF+ISe0jZwvAUJzMmLLMppVvEqGDuJF1mjTQkj4kqEE=; b=Qd4XuVlzKJrVpVDs63rVPTKjVg+rHF2Xdo3Hu++KPMjHTBhjIDKgNEVvWawQpq6Vxc ua5iz81eZEqg+i0VauiOu8gZ0/0jmJ8b19pa1f/XjBEOU5PUjBaK1vqcFInUObEKVMJw fFrwQZrjnZxee1X+Ry1GGxljKBYeZuIOvBNBMMqzP5oMiqwzTGRgt+vW7ULeQUY91mm+ F1VE1dqq86lBmiu+AfRHc9t886j+XeRHmYdGeboO+zF3ZyAIsnCxtX9PIonjJQFpwHLn vhu2Rw8qRNA6hV9oTN4hhU44fjrB4AolSwVH9nSgexThtJ7iOXcFTpjHwyaMcTwPp8v3 goyQ== X-Gm-Message-State: AOAM532rlQl3y4bqltRm0eevtxbtaBrZbUQrRoY49TQFV/C9mjrTnfoC GMp85vPFPA2yIKjPZgJ6RTZjbfBWCNv9iYHZeqI= X-Google-Smtp-Source: ABdhPJxYDssD4axVekBitB/qkdVqYSKJpmLXg3Q96rldGfWMfDzBwO7wQ0jX50hKe3OrFpbU0ykT3ygZE49ERR6SuB8= X-Received: by 2002:a05:6830:2244:: with SMTP id t4mr1951130otd.125.1620128894844; Tue, 04 May 2021 04:48:14 -0700 (PDT) MIME-Version: 1.0 References: <87h7jqguew.fsf@oldenburg.str.redhat.com> In-Reply-To: <87h7jqguew.fsf@oldenburg.str.redhat.com> Date: Tue, 4 May 2021 04:47:38 -0700 Message-ID: Subject: Re: [RFC] elf: Implement filtering of symbols historically defined in libpthread To: Florian Weimer Content-Type: text/plain; charset="UTF-8" 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: "H.J. Lu via Libc-alpha" Reply-To: "H.J. Lu" Cc: Andreas Schwab , GNU C Library Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On Wed, Apr 28, 2021 at 1:37 PM 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. > > 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). > Since we want to detect the binaries which were linked against glibc older than 2.34, we should use the glibc version to check the old binaries. Of course, we should make a complete list of functions which are really implemented in libpthread.so and will be moved to libc.so in glibc 2.34. H.J.