From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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> From: "H.J. Lu" 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 Cc: GNU C Library , Andreas Schwab Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3028.6 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: Tue, 04 May 2021 13:06:51 -0000 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.