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.129.124]) by sourceware.org (Postfix) with ESMTPS id AC104386001F for ; Mon, 31 Jan 2022 16:48:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AC104386001F Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-353-KouoxqLdNdiI5qcW44I3Kw-1; Mon, 31 Jan 2022 11:48:01 -0500 X-MC-Unique: KouoxqLdNdiI5qcW44I3Kw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9C39E86A8A1; Mon, 31 Jan 2022 16:48:00 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.193.205]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7868A8276A; Mon, 31 Jan 2022 16:47:59 +0000 (UTC) From: Florian Weimer To: "H.J. Lu" Cc: Alan Modra , Binutils Subject: Re: [PATCH] elf: Don't set VER_FLG_WEAK References: <20220126001953.652545-1-hjl.tools@gmail.com> Date: Mon, 31 Jan 2022 17:47:57 +0100 In-Reply-To: (H. J. Lu's message of "Wed, 26 Jan 2022 05:26:34 -0800") Message-ID: <87k0ef7sxu.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.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2022 16:48:04 -0000 * H. J. Lu: > On Tue, Jan 25, 2022 at 7:07 PM Alan Modra wrote: >> >> On Tue, Jan 25, 2022 at 04:19:53PM -0800, H.J. Lu via Binutils wrote: >> > On Solaris, VER_FLG_WEAK indicates a weak version definition with no >> > symbols associated with it. It is used to verify the existence of a >> > particular implementation without any symbol references to the weak >> > version. Don't set VER_FLG_WEAK since it is unused in binutils. >> >> Can you tell me why the presence of this flag is bad? I don't see it >> affecting anything in binutils or glibc. VER_FLG_WEAK in version refs >> does affect resolution of symbol, but I can't see how a VER_FLG_WEAK >> in a version def can transfer over to a ref if the def is unused. > > Florian, can you share the reason why Linux doesn't want > VER_FLG_WEAK on the empty version? I may have been overly cautious, influenced by the old link editor behavior which copied the weak flag of dynamic symbols from the definitions to their references. But it's indeed unclear how this could happen here. If it did, we would lose the coverage check in the glibc dynamic loader for that symbol version, I think. (The loader only checks vna_flags in two places, once for printing the flag, and once to skip an error report in case of a missing version.) Do you suggest we should start using weak symbol version definitions in glibc, and not worry about it? Thanks, Florian