From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) by sourceware.org (Postfix) with ESMTPS id 751FB38515DC for ; Mon, 10 May 2021 14:02:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 751FB38515DC Received: by mail-ot1-x32e.google.com with SMTP id t4-20020a05683014c4b02902ed26dd7a60so4341492otq.7 for ; Mon, 10 May 2021 07:02:47 -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=c9ij92hQfG7bKEWN0YvQCqOFtLfOcCiWXnzM5SWWey8=; b=Is6wgW8UBWznVkT42YMCSpq/kBIDxes5r/pUr6pUmkfxvvO40hpFXCUoqgCKmXB3J4 9KTQK3qdI+tafPs1CjklpUh77AbsEPad7pCc3AEyzXulRm+023s/e2rC5hDROO1KLzGs HgOx15BkblxSd3+7qNf/evGE2+NhSnIzNVK9Za+avz6r71mtk8RKbfgTxqLvYC8Bo4co RJy7L5YhE53Q99lAtZbfXmGr0RHGgKjxY296+NIq/+haiDJVvlza9ddJ062z2d9R+G/V eESSZd2pbTNAqQRzHIw+oENpXY9YivJmakfADj/p/hRr/WD9VuE5aHGBuN5mrzC6S+Fh uRAg== X-Gm-Message-State: AOAM531fuX9azcNtBAXsmWqEkQk78pWsywsZalp8JwNyRQS+MGoN5bHw LgcMUgYqqzomj96y4H5A0ex16hcr59J3y9yELXbr+4cx9VSVMQ== X-Google-Smtp-Source: ABdhPJxg4LZqrabsOZRfih1Mwja+U37FiespW3M0jTFJWabJyTcBgQqcY1QOPSU29tKuMYxxPTmigDv8i5YC+WaW4zc= X-Received: by 2002:a9d:67cf:: with SMTP id c15mr21250159otn.285.1620655366794; Mon, 10 May 2021 07:02:46 -0700 (PDT) MIME-Version: 1.0 References: <87eeelfg77.fsf@oldenburg.str.redhat.com> <87k0oabnzq.fsf@oldenburg.str.redhat.com> <87a6p2bsyc.fsf@oldenburg.str.redhat.com> In-Reply-To: <87a6p2bsyc.fsf@oldenburg.str.redhat.com> From: "H.J. Lu" Date: Mon, 10 May 2021 07:02:10 -0700 Message-ID: Subject: Re: [PATCH v2] elf: Implement filtering of symbols historically defined in libpthread To: Florian Weimer Cc: Florian Weimer via Libc-alpha , Andreas Schwab Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3027.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, 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-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: , X-List-Received-Date: Mon, 10 May 2021 14:02:48 -0000 On Mon, May 10, 2021 at 6:48 AM Florian Weimer wrote: > > * H. J. Lu: > > > On Fri, May 7, 2021 at 9:29 AM Florian Weimer via Libc-alpha > > wrote: > >> > >> Given that there is no consensus on the exact direction and Andreas does > >> not need it after the binutils fix, I'm going to drop this patch for > >> now. > >> > >> As I said, I might come back to this if we learn that users have many > >> binaries that they can't rebuild and that no longer work because weak > >> symbols are bound unexpectedly. > >> > > > > But we should hide symbols for undefined, weak, unversioned references > > from the old versioned binaries. > > What's an old binary? > > Say something linked against glibc has a weak unversioned dependency on > execveat (a new function in glibc 2.34). Should running this program on > glibc 2.34 use glibc's execveat function or not? > No. The program will still run with glibc 2.34. This is a compromise and safer. We can have execveat@@GLIBC_2.40 which has issues for callers which expect execveat@GLIBC_2.34. -- H.J.