From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by sourceware.org (Postfix) with ESMTPS id 56322383D800 for ; Fri, 27 May 2022 21:03:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 56322383D800 Received: by mail-pj1-x1029.google.com with SMTP id cv10so5580973pjb.4 for ; Fri, 27 May 2022 14:03:17 -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=Zffz2PhzxKGcXJMHf1R0/PfidC4kxv8K7SpaZhc9Cgs=; b=xmqFF66N5ZPeCxb1P9XPLdcTwpi2oyF+YBV/3EMyyJJUwani6F7qiS5JkmXa6YPyqL h71q+4MWo8rzP3ECm9bDqoJLbtqMR2MrEUqKWF6cWqfoOaQnoL4XQ3LFSn2fQY220roL diqYjJWbpo1xjv9ZTyOx5TcXCLiIv6Y5QqiO3HGpPa7IjC7y9b9TWgjskJCcGKZ7oiPs yiRJu/AVz/2xYk5uwZp6e2mTKwBpE4KxLHl+OABsRua6cfmwdK6oLL8qI0U3vpHdf+C1 IK7xkeU38PCqeJaRp8KoWbde1MEBQN3N6SMXE1iGy28K+obUuI0IfPyIMxlhR8GnNwW0 CtvQ== X-Gm-Message-State: AOAM530ny6iPlo+2Joe4S1tNQXfVXxMgmS2aIzDXv9yR45tmV4jW2Dv9 9Rxd2O4JcIcCMUy86zIplVmcxQ== X-Google-Smtp-Source: ABdhPJxg0WNUyKEpOTWfm9jVhE3zuHK/21/y0t6ZmC8hmJuKWJAXWTjToO+246ztZoTQ8CivIRxJaQ== X-Received: by 2002:a17:90a:5886:b0:1dc:6b58:91e with SMTP id j6-20020a17090a588600b001dc6b58091emr10361330pji.176.1653685396168; Fri, 27 May 2022 14:03:16 -0700 (PDT) Received: from google.com ([2620:15c:2ce:200:781f:286a:7724:6870]) by smtp.gmail.com with ESMTPSA id bx20-20020a056a00429400b0050dc76281bdsm3892178pfb.151.2022.05.27.14.03.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 May 2022 14:03:15 -0700 (PDT) Date: Fri, 27 May 2022 14:03:12 -0700 From: Fangrui Song To: Florian Weimer Cc: libc-alpha@sourceware.org Subject: Re: [PATCH] dlsym: Make RTLD_NEXT prefer default version definition [#BZ #14932] Message-ID: <20220527210312.oi3oakg5g5ao7y3f@google.com> References: <20220520083507.2368165-1-maskray@google.com> <87k0a7fd9n.fsf@oldenburg.str.redhat.com> <20220527192448.n7bny5g3eyxou5xo@google.com> <20220527203202.r5vmk5ssufem4jga@google.com> <87leumd83e.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <87leumd83e.fsf@oldenburg.str.redhat.com> X-Spam-Status: No, score=-20.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: Fri, 27 May 2022 21:03:19 -0000 On 2022-05-27, Florian Weimer wrote: >* Fangrui Song: > >> I suspect the code (from 199x) has a hidden assumption that for a stem >> symbol (say foo), the .dynsym entries (say foo@v1, foo@v2, foo@@v3) are >> ordered by the version node indices (in .gnu.version_d). > >Right, the code clearly has this assumption. There has to be some >ordering because we don't want to do a topological sort to find the >lowest and highest versions. > >> If so: >> >> * (flags & DL_LOOKUP_RETURN_NEWEST) == 0 => the symbol with >> verstab[symidx]==2 will skip the check and be returned >> * (flags & DL_LOOKUP_RETURN_NEWEST) != 0 => only the default version >> symbol gets assigned in `*versioned_sym = sym` >> >> Unfortunately, this assumption hold for none of GNU ld, gold, and >> ld.lld (seems unrelated to --hash-style=): >> >> ``` >> % ld.bfd @response.txt && readelf -W --dyn-syms nextmod3.so | grep foo@ >> 5: 0000000000001100 6 FUNC GLOBAL DEFAULT 13 foo@v1 >> 8: 0000000000001120 6 FUNC GLOBAL DEFAULT 13 foo@@v3 >> 9: 0000000000001110 6 FUNC GLOBAL DEFAULT 13 foo@v2 >> % gold @response.txt && readelf -W --dyn-syms nextmod3.so | grep foo@ >> 7: 00000000000007c0 6 FUNC GLOBAL DEFAULT 14 foo@@v3 >> 9: 00000000000007a0 6 FUNC GLOBAL DEFAULT 14 foo@v1 >> 10: 00000000000007b0 6 FUNC GLOBAL DEFAULT 14 foo@v2 >> % ld.lld @response.txt && readelf -W --dyn-syms nextmod3.so | grep foo@ >> 7: 0000000000001740 6 FUNC GLOBAL DEFAULT 13 foo@@v3 >> 8: 0000000000001720 6 FUNC GLOBAL DEFAULT 13 foo@v1 >> 9: 0000000000001730 6 FUNC GLOBAL DEFAULT 13 foo@v2 > >The order of symbols in the symbol table is not what counts here, it's >the order in the list for the hash bucket. > >I'm not sure if it's possible to dump this with readelf. I'm writing a >custom dumper for this. > >Thanks, >Florian > llvm-readelf --gnu-hash-table can dump the chain array (`Values:`), with the size equal to the number of defined symbols. The odd numbers indicate the end of a chain. I believe the .gnu.hash lookup order is in increasing symbol index (in all of musl, glibc, FreeBSD rtld). So the glibc (flags & DL_LOOKUP_RETURN_NEWEST) == 0 code path (for relocations) is wrong...