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=-4.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham 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 6AC001F5AE for ; Tue, 4 May 2021 12:37:54 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D70863989C96; Tue, 4 May 2021 12:37:37 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D70863989C96 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1620131857; bh=rBfRq29tszc+bO0no1JDc4sRQ1yqVuTI4FVBqgbmHzA=; 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=yqTsOY3lgCp5ViaRkYqy8glrAC9zBFH3T+9XNOwfHyYOi1UQEq0ymQD3QC1SdkABv P98Bxal6eMel/h9WUA2mDivhMkOZg3omuxzHPjWwO2FvHpo/mpiTPJ1eiD9uL9dtFw QvGsLx6mBdPtilSBVWly0Dz78hX27lzGX5bR1UfU= Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) by sourceware.org (Postfix) with ESMTPS id 242BD3951C66 for ; Tue, 4 May 2021 12:37:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 242BD3951C66 Received: by mail-oi1-x22a.google.com with SMTP id u16so8579222oiu.7 for ; Tue, 04 May 2021 05:37: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:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rBfRq29tszc+bO0no1JDc4sRQ1yqVuTI4FVBqgbmHzA=; b=W2wPcURyOz0eYRLlZq4POqQM1Wl7YoZNkPB9tJC4ytAFqFO5004QgPWM/T9dluFgL1 cbpXCJ24mi64iat7KzEi3ucO989+A1ETMO+ilJp6WtgD5ys1TDcHuxtKSbmUNskFnAQU WlcIXGfWq7HX/BbGA6KL02KA40jtJR9OO1ZPxXbGpYJkH7b0/9E1STfRfBG1ik4Bb9YA 8vaZNUa9pUO7Nq2VJM72S3zpczDviqA2vY+Ko5BI9wZPwXOvg+ZQEuUjXvoyaGKKFEY9 56FInlCtyS4yPvO/3HoCUyShVgpn5D0uOQqx7eqJrua3jdGT5+Jly7QZ36bRQtBXpyB1 KACg== X-Gm-Message-State: AOAM532YVj0XmLDguwFCqKRVG+CHKpfTVdraOkHGTxU/EoeCSIyIubuN nLgfyJNcNgIuZTFe3rMTPttiQSZKJAnw3iHtpZU= X-Google-Smtp-Source: ABdhPJwMsz0p+ZjeMwf/hbAhIgAX/ezrLlQWJS1ymJtu8Wmn2Ra09JmdmZgOAUOpWZeTAvFGoSlUtq6fsgG6RNdqK0c= X-Received: by 2002:aca:bdc6:: with SMTP id n189mr2863505oif.156.1620131853639; Tue, 04 May 2021 05:37:33 -0700 (PDT) MIME-Version: 1.0 References: <87h7jqguew.fsf@oldenburg.str.redhat.com> <87k0oeln6s.fsf@oldenburg.str.redhat.com> <87wnsek7ku.fsf@oldenburg.str.redhat.com> <87sg32k79x.fsf@oldenburg.str.redhat.com> In-Reply-To: <87sg32k79x.fsf@oldenburg.str.redhat.com> Date: Tue, 4 May 2021 05:36:57 -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 Tue, May 4, 2021 at 5:33 AM Florian Weimer wrote: > > * H. J. Lu: > > > On Tue, May 4, 2021 at 5:27 AM Florian Weimer wrote: > >> > >> * H. J. Lu: > >> > >> >> The patch attempts to detect old main programs by looking for the > >> >> GLIBC_2.34 symbol version. Since we added __libc_start_main@@GLIBC_2.34 > >> >> (which is called from our version of _start), all standard main programs > >> >> linked with glibc 2.34 or later will have this symbol version. > >> > >> > Can we invent a symbol or version to detect the older binaries? > >> > If not, can GNU property, ABI note, .... help here? > >> > >> I think we have all we need due to __libc_start_main@@GLIBC_2.34. It > >> was an unrelated change, but it helps here as well. > > > > So your patch isn't required? Can you add some tests to verify it? > > No, the patch uses the absence of GLIBC_2.34 for detecting old binaries. > > We cannot use symbol versions in other ways because one key > characteristic of weak references and underlinking is the lack of > version information on the symbol itself. Can we add support for binary testcases like this, even if it can only run on a single target? It shouldn't be too hard. -- H.J.