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 7A3031F5AE for ; Tue, 4 May 2021 13:07:10 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9B7ED3958C29; Tue, 4 May 2021 13:06:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9B7ED3958C29 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1620133613; bh=fiZfBPe+XP4dk5LhOz+QIfULhGiB3Pg8nwdqWRrI2Hs=; 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=DwCQje7jIaysEuzbeH9lfR7LjmsC4K/Td8Ad4F4cO/agW4coE3U/vGReHy0smt38+ XoBjMKeXxz1bqKh0z75E4KlkkCKMlrw34RNF+0pGdsQwRcGipILuEW+G4Rh59YO0XU Gi1cHJb4BTjvyWbb6K9f/YzxAoSUolA8xqns2G5o= Received: from mail-oo1-xc35.google.com (mail-oo1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) by sourceware.org (Postfix) with ESMTPS id 4AF653951C9F for ; Tue, 4 May 2021 13:06:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4AF653951C9F Received: by mail-oo1-xc35.google.com with SMTP id t17-20020a4a3e110000b02901fab2f46a48so1988746oot.6 for ; Tue, 04 May 2021 06:06:50 -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=fiZfBPe+XP4dk5LhOz+QIfULhGiB3Pg8nwdqWRrI2Hs=; b=fUvZZhpSXa3xHQUcgySOHuARVQv9nVACXuTzJeGa0NGa8OhlVjZ6dU1kB1a7mjmmoG /Dlb0LdevsK2grbG+3VTcGezsjGr+5LBh9MUBW5zo5GmOa7jVHsytqc1pKXh3jH1wCrh FAZw6X7foKcPD4611hzsRtfQxW5r80E9iufg9aULoYQeXJ/6wSSRJEn4Y8eoyzVw6YLf dfvRPpeASkPbV1oDQlxDwkjwHNT8oQueA/B4xVXfi82R+cxHmA+TlwZ4hDl0VtlnFQkR tr6PJ8iq+AvXKyd0acP7nQna7yfrBdIxGumFWfxRPAIaqIHjxa0HUPfgqLB2e/V3jBY5 bWIg== X-Gm-Message-State: AOAM533WTZWepGSnahQ/K8/Vg7Job8Zv8LhBTnkzteU6Y3YPmGpla1TR YCliQr1TGmh6zbdDYa+U15ps/5ARAGWqk843kWg= X-Google-Smtp-Source: ABdhPJyyyTJIN737iPy2oTjQNYnihz0gIzmA7mCVgQfdKKI32wOCBPQJ6aAErOD4iNNnKqBrTmYan5QgIuO/sNLFPTs= X-Received: by 2002:a4a:5242:: with SMTP id d63mr14997898oob.93.1620133608391; Tue, 04 May 2021 06:06:48 -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> <87lf8uk6u2.fsf@oldenburg.str.redhat.com> In-Reply-To: <87lf8uk6u2.fsf@oldenburg.str.redhat.com> Date: Tue, 4 May 2021 06:06:12 -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:43 AM Florian Weimer wrote: > > * H. J. Lu: > > > 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. > > Yes, we can verify the binding status of weak symbols with a smaller > assembler program that was linked against a stub libc.so.6 library that > only contains the soname and no symbols. > > As the code is architecture-agnostic, testing on e.g. x86-64 should be > sufficient. > > We cannot easily verify the behavior of real-world binaries because > re-linking them with current binutils probably changes behavior. Why re-linking is needed for the binary executable test? -- H.J.