From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id AEB9E383B7B1 for ; Fri, 27 May 2022 20:38:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AEB9E383B7B1 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-602-cpk45ojFOL6cSmgIbbyB7w-1; Fri, 27 May 2022 16:38:35 -0400 X-MC-Unique: cpk45ojFOL6cSmgIbbyB7w-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 1CAF8101AA47; Fri, 27 May 2022 20:38:35 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.71]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A13541121315; Fri, 27 May 2022 20:38:33 +0000 (UTC) From: Florian Weimer To: Fangrui Song Cc: libc-alpha@sourceware.org Subject: Re: [PATCH] dlsym: Make RTLD_NEXT prefer default version definition [#BZ #14932] References: <20220520083507.2368165-1-maskray@google.com> <87k0a7fd9n.fsf@oldenburg.str.redhat.com> <20220527192448.n7bny5g3eyxou5xo@google.com> <20220527203202.r5vmk5ssufem4jga@google.com> Date: Fri, 27 May 2022 22:38:29 +0200 In-Reply-To: <20220527203202.r5vmk5ssufem4jga@google.com> (Fangrui Song's message of "Fri, 27 May 2022 13:32:02 -0700") Message-ID: <87leumd83e.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, 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 20:38:39 -0000 * 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