From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49450 invoked by alias); 16 Mar 2018 17:39:04 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 49440 invoked by uid 89); 16 Mar 2018 17:39:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=foundational X-HELO: mail-qk0-f174.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ojL0Qq8qNTENLCuS05Dryh0YDqePT8B2jqetijrNeNw=; b=RP+OkSHd2Kc4VO3iWsor5Ziegs7DxGr3Smazw+VrLXtK8PLN1GH3q3U9NHLHftJ3IM WuaHJgpxVlrhAc6VzfoCq3pVbF4ONHtf7p+LRTjsKNJTXMJRu6sZxbECSPpbV1dDxK/x V8qzZkaUorluzNxUE4CIfQkKJ6ES8iFdjhmKPjehpOY6dVSZy+od2Z2NgwG5+C9KN7kt EfpEJOV6JhVL//0LIPMuJXRkblTCqBkuOPqCsQFH/m/1BRS+nU4HQm8m2oQD2u5RZvGa KppDoxbKc7e2rJmOB9sDqVN+VCvLs2pk7o6kozpIlkWji3UYo0IlRUcrFroMPaFBZiYk /+og== X-Gm-Message-State: AElRT7Gh+3un0l4Qe38sr/S2o83swA1ZCwxSYutnmSjKYnBbCKBtAqyb gRo+pfJA6iGB7SBR1mAck1Tl+Lk6Lc0= X-Google-Smtp-Source: AG47ELuvwTLQsv3DA1vjJ45vTreIUlBFIwJQmU6Fv9ZcRWrZVixpMboSEeYAcvhOMojYsTWdwJo17A== X-Received: by 10.55.36.132 with SMTP id k4mr3863497qkk.68.1521221940125; Fri, 16 Mar 2018 10:39:00 -0700 (PDT) Subject: Re: Are the pthread "compatibility" copies of symbols in libc still necessary? To: Florian Weimer , Zack Weinberg , GNU C Library References: <2b40c294-fd0a-048d-06d5-c872f381729d@redhat.com> <0e42476f-fbdb-e82f-f908-aaf8af63e6db@redhat.com> From: Carlos O'Donell Message-ID: Date: Fri, 16 Mar 2018 17:39:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <0e42476f-fbdb-e82f-f908-aaf8af63e6db@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2018-03/txt/msg00408.txt.bz2 On 03/16/2018 09:42 AM, Florian Weimer wrote: > On 03/16/2018 04:35 PM, Carlos O'Donell wrote: >> On 03/16/2018 08:41 AM, Florian Weimer wrote: >>> On 03/16/2018 03:30 PM, Zack Weinberg wrote: >>>> A number of source files that properly belong to libc.so are also >>>> compiled as part of libpthread, with a note that this is for >>>> "compatibility for old binaries".  The exact set varies based on >>>> architecture, but includes basic things like read, write, and fork - I >>>> _think_ there was a difference in semantics in the distant past, >>>> having something to do with thread cancellation. >>> >>> They are still needed because versioned symbols also embed a DSO name, and the dynamic linker checks that if it has not been interposed. >>> >>> I think it's this code in elf/dl-lookup.c: >>> >>>        if (__glibc_unlikely (res < 0) && skip_map == NULL) >>>      { >>>        /* Oh, oh.  The file named in the relocation entry does not >>>           contain the needed symbol.  This code is never reached >>>           for unversioned lookups.  */ >>>        assert (version != NULL); >>>        const char *reference_name = undef_map ? undef_map->l_name : ""; >>>        struct dl_exception exception; >>>        /* XXX We cannot translate the message.  */ >>>        _dl_exception_create_format >>>          (&exception, DSO_FILENAME (reference_name), >>>           "symbol %s version %s not defined in file %s" >>>           " with link time reference%s", >>>           undef_name, version->name, version->filename, >>>           res == -2 ? " (no version symbols)" : ""); >>>        _dl_signal_cexception (0, &exception, N_("relocation error")); >>>        _dl_exception_free (&exception); >>>        *ref = NULL; >>>        return 0; >>>      } >>> >>> This is required by the GNU symbol versioning spec, but I don't know why. >> >> The specification says the data must be recorded, but it doesn't say what you >> have to *do* with the data? > > It does: > > “ > A fatal error shall be triggered when no matching definition can be > found in the object whose name is the one referenced by the vn_name > element in the Elfxx_Verneed entry. > ” I don't know what drove this requirement. >From a first-principles perspective is doesn't seem to derive from any foundational aspect of the linkage model. Can you rationalize the requirement yourself? Am I missing something? >>> Even new binaries use these symbols: >>> >>> $ LD_DEBUG=bindings systemctl |& grep binding.*system.*libpthread.*[^_]fork >>>       11905:    binding file /usr/lib/systemd/libsystemd-shared-234.so [0] to /lib64/libpthread.so.0 [0]: normal symbol `fork' [GLIBC_2.2.5] >>>       11905:    binding file systemctl [0] to /lib64/libpthread.so.0 [0]: normal symbol `fork' [GLIBC_2.2.5] >>> >>> This may be a linker bug because at least fork is a compat symbol. > >> Is it a dynamic loader bug that the compat symbol was selected? > > No, I don't think the dynamic linker has to make this distinction, at > least not if the soname matches the one in the version. I think the problem is that the two checks are orthogonal. You have one check to find the versioned symbol based on lookup scopes. You have another check to determine if a DSO with the appropriate symbol and version exists. Both of these are true in the fork case. >> My conclusion is this: >> >> * We can remove fork@GLIBC_2.2.5 from libpthread.so, the shared object doesn't >>    encode it as being needed and won't cause a failure per the rules that >>    require the referenced shared object to have the versioned symbol that was >>    bound at static link time. > > I already tried a while bug and failed because the system does not > boot anymore after that, due to the check mentioned above. I don't > think the code has changed since then. Do you know what failed? I should try this. Cheers, Carlos.