From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x2a.google.com (mail-oa1-x2a.google.com [IPv6:2001:4860:4864:20::2a]) by sourceware.org (Postfix) with ESMTPS id 15DA638387F9 for ; Fri, 27 May 2022 21:15:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 15DA638387F9 Received: by mail-oa1-x2a.google.com with SMTP id 586e51a60fabf-f16a3e0529so7207034fac.2 for ; Fri, 27 May 2022 14:15:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=B4ZgeB99RU6eQ25Nj45Ss7qvoNL9wtkGNBHQQ+/XfSw=; b=eDacmH9tOuDpHRHU7dgFjGEATl/xCXX6Mqz8WNTkpNmx0kfNj+N+gSdqFQwUJ5zwcX 9N/TomSs5KgAQLONRTa9/q7NlsXd7oRsc7AO6My1YkpB+MFKqqg1dhBFo7QmUJBf9XyZ jS2xQjT4Zlv4obel/XjhkP+cnIvYErR/FxtO/uypJWNNQfeMT7CziWOVrRRq6PggJckI 45V36ZuVa79D8GZxfE/XY16NujrQkl4Qo4eNnvqtFsKOvMFd/RLyAc+Dj/8DZ/N3DWCa wxGNL4cdz2Bucaer+EAsU51qg3R07AKbj70h5WnSgTUFXVCwCY6UUzm97QhZzaujSeXN gEmw== X-Gm-Message-State: AOAM531+29XxxkSgvy6cpZbl4w3yktM3DPsKDb0Ajp8awYjGfcolDy4f p6cebq8RE2fDS93DfYxJDYY4EQ== X-Google-Smtp-Source: ABdhPJyvzUBxzoRg86gsGMgJSzxDf4m/1Yq0PA9cLFHPd377rD/syPqKmJ8jJnDOerk1ievuFYYCPQ== X-Received: by 2002:a05:6870:434b:b0:f1:e2d9:dc66 with SMTP id x11-20020a056870434b00b000f1e2d9dc66mr4862082oah.86.1653686114258; Fri, 27 May 2022 14:15:14 -0700 (PDT) Received: from ?IPV6:2804:431:c7cb:9f85:b770:666d:a956:2e6a? ([2804:431:c7cb:9f85:b770:666d:a956:2e6a]) by smtp.gmail.com with ESMTPSA id bm8-20020a0568081a8800b00325cda1ffabsm2173496oib.42.2022.05.27.14.15.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 May 2022 14:15:14 -0700 (PDT) Message-ID: Date: Fri, 27 May 2022 18:15:11 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH] dlsym: Make RTLD_NEXT prefer default version definition [#BZ #14932] Content-Language: en-US To: Fangrui Song , Florian Weimer Cc: libc-alpha@sourceware.org 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> <20220527210312.oi3oakg5g5ao7y3f@google.com> From: Adhemerval Zanella In-Reply-To: <20220527210312.oi3oakg5g5ao7y3f@google.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE 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:15:18 -0000 On 27/05/2022 18:03, Fangrui Song via Libc-alpha wrote: > 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... My understanding is (flags & DL_LOOKUP_RETURN_NEWEST) == 0 is only used for dlvsym and I think we never documented properly hwo dlvsym (handle, symbol, "") should behave. Currently it is different than dlsym (handle, symbol) (it will return the a versioned symbol), while with your patch it will be similar to dlsym.