From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [46.235.227.227]) by sourceware.org (Postfix) with ESMTPS id 182603857021 for ; Tue, 23 Feb 2021 00:17:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 182603857021 Received: from collabora.com (unknown [IPv6:2001:4d48:ad5c:ef00:8e70:5aff:fe59:c29c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: vivek) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 484BA1F4527B; Tue, 23 Feb 2021 00:17:44 +0000 (GMT) Date: Tue, 23 Feb 2021 00:17:39 +0000 (GMT) From: =?UTF-8?Q?Vivek_Das=C2=A0Mohapatra?= X-X-Sender: vivek@noise.cbg.collabora.co.uk To: Adhemerval Zanella cc: libc-alpha@sourceware.org Subject: Re: [RFC][PATCH v8 18/20] Add DT_GNU_FLAGS_1/DF_GNU_1_UNIQUE dynamic section+flag to glibc DSOs In-Reply-To: Message-ID: References: <20210209171839.7911-1-vivek@collabora.com> <20210209171839.7911-19-vivek@collabora.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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, 23 Feb 2021 00:17:46 -0000 > We have some options to fix it: > > 1. Bump the minimum supported binutils version to 2.36. It would be > a large change, since we usually do incremental changes over releases It's a large bump: OTOH is it the case that people are going to be rolling out cutting edge glibc with old binutils? (Serious question, the answer might be yes in whic case we do need to think about this). > 2. Add a configure check and enable RTLD_SHARED iff ld supports > -z unique. It would require return EINVAL is RTLD_SHARED or Doable, but then we'd have glibc at the same version with different capabilities/behaviours in the linker: Asking for pain imo. > 3. Find a way to force add DF_GNU_1_UNIQUE on older binutils > (since its support is just a dynamic section existence) I think this is doable, either with a linker script or by using the spare dynamic tags added by ld (cf --spare-dynamic-sections) and writing in the value we want in the first spare slot. I'll have a look at adding this since it enables the feature with minimal friction for distributions/users/etc.