From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) by sourceware.org (Postfix) with ESMTPS id B7701395561E for ; Tue, 31 May 2022 06:24:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B7701395561E Received: by mail-pj1-x1031.google.com with SMTP id w2-20020a17090ac98200b001e0519fe5a8so1317301pjt.4 for ; Mon, 30 May 2022 23:24:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=4KdJkUxp8MhLwo9lUysTI68TptC0YgJXgQi/yDVIuco=; b=fagpnfxTeNj/5cNLF2eNmkShPNnM7dlXzwwjUT0i9hxTiZ5Ydp90a/mayhSQxyESft wCn/Qv65Z0bQB3mAFIPSso+xpCFK0iaO1RLVGRm1IZn16rCb/B/VG62OiGBPm909qPYw nNUJaYon6sCnPRCCLU14B1xmtw+LbJ/8nS+k89aUv142Loey4iH9XQ+pRTEs9sx/UV4D zH22BKaH8VbQJ0gggCeI6wPEPTmaRk+9BdcIchwB/FZ2kBJMPvwGWfMpPcqJTAMO74ld 9nQmkHHyWr2TdpP9Yfq4CTz3hojSOgy9LJzlQo8sObkxZWEnnr3UnAV21tPMwyoqlZif 79rA== X-Gm-Message-State: AOAM533FrVdDA22xvOgeIy012N9cemusalpO+m92IuYoSJrk1R087NQ6 fUiOiXwd4u4NGz2u/zLuyNGQGeCaVvw0jw== X-Google-Smtp-Source: ABdhPJx4qWSobf43GKlrbiUuiL2WyIp6rAthZLra5bFNO/PSfznl4ph9QevxWjeTQGkR8n2Y3W9fnA== X-Received: by 2002:a17:90a:1c02:b0:1e0:df7:31f2 with SMTP id s2-20020a17090a1c0200b001e00df731f2mr27490525pjs.222.1653978298419; Mon, 30 May 2022 23:24:58 -0700 (PDT) Received: from google.com ([2620:15c:2ce:200:fb0a:168d:1d08:ca3]) by smtp.gmail.com with ESMTPSA id h9-20020a170902f54900b0016223016d79sm10384903plf.90.2022.05.30.23.24.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 May 2022 23:24:57 -0700 (PDT) Date: Mon, 30 May 2022 23:24:54 -0700 From: Fangrui Song To: Florian Weimer Cc: Fangrui Song via Libc-alpha Subject: Re: [PATCH v2] elf: Remove one-default-version check when searching an unversioned symbol Message-ID: <20220531062454.akct4tb2jnonbxnh@google.com> References: <20220528005658.1088272-1-maskray@google.com> <87o7zfi2x9.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <87o7zfi2x9.fsf@oldenburg.str.redhat.com> X-Spam-Status: No, score=-19.9 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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, 31 May 2022 06:25:01 -0000 On 2022-05-30, Florian Weimer wrote: >* Fangrui Song via Libc-alpha: > >> - sym = num_versions == 1 ? versioned_sym : NULL; > >> + sym = versioned_sym; > >This change is rather suspicious. If we discard the return value this >way, why have a distinct out parameter at all? versioned_sym is a fallback when sym is still NULL on this line. When there is a version index 2 and DL_LOOKUP_RETURN_NEWEST is not set, version index 2 takes precedence over the default version. The code needs to remember the default version in case a definiton of index 2 is absent. Perhaps renaming `versioned_sym` to `default_version_sym` may be clearer? >More generally, the default version at index 2 is necessarily a global >default, e.g. for x86-64, it is always GLIBC_2.2.5 for any symbol. The term "default" has ambiguity. It may refer to the visibility STV_DEFAULT or the property of a version: default vs non-default (hidden). For a symbol name, there can be at most one default version and any number of non-default (aka hidden) versions. The default version does not need to be at index 2. In glibc, I think generally the last version index is the default and the others are non-default. However this is not a requirement in the linker. That said, linkers guarantee that version nodes in a version script get increasing version indices. >But >we have symbols whose non-default version is *later* than GLIBC_2.2.5. >I want to understand better how that information is encoded. Yes. Some symbol names have more than one non-default versions, e.g. % nm -jpD /lib/x86_64-linux-gnu/libc.so.6 | grep \^sys_errlist sys_errlist@GLIBC_2.12 sys_errlist@GLIBC_2.2.5 sys_errlist@GLIBC_2.3 sys_errlist@GLIBC_2.4 The version node with index 2 is GLIBC_2.2.5. When DL_LOOKUP_RETURN_NEWEST is unset, an unversioned symbol lookup prefers GLIBC_2.2.5 over the default version if exists. The behavior is to retains compatibility when a shared object becomes versioned: the symbols with the smallest version (index 2) indicate the previously unversioned symbols. If a new version of a shared object needs to deprecate an unversioned bar, you can remove bar and define bar@GLIBC_2.2.5 instead. Libraries using bar are unaffected but new linking against bar all gets versioned references. >If possible we should avoid scanning the entire hash chain for >unversioned symbols and pick the version with lowest or highest index >(for binding or dlsym), but I don't know if we can. This could be achieved if @xxx were part of the hashed string, but the .hash/.gnu.hash designs had chosen to hash only the unversioned part, so this situation could not be improved now...