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 53471386F836 for ; Wed, 17 Jun 2020 16:37:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 53471386F836 Received: from collabora.com (unknown [IPv6:2001:4d48:ad56:3000:88ff:22ff:81f3:30c8]) (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 82B6A2A41C1; Wed, 17 Jun 2020 17:37:39 +0100 (BST) Date: Wed, 17 Jun 2020 17:37:33 +0100 (BST) From: =?UTF-8?Q?Vivek_Das=C2=A0Mohapatra?= X-X-Sender: vivek@noise.cbg.collabora.co.uk To: Michael Matz cc: gnu-gabi@sourceware.org Subject: Re: [RFC][PATCH v2 0/6] binutils patches to add DT_GNU_UNIQUE In-Reply-To: Message-ID: References: <20200617135945.12716-1-vivek@collabora.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-ID: X-Spam-Status: No, score=-8.4 required=5.0 tests=BAYES_00, KAM_ASCII_DIVIDERS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; CHARSET=UTF-8; FORMAT=flowed Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gnu-gabi@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnu-gabi mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 16:37:41 -0000 On Wed, 17 Jun 2020, Michael Matz wrote: > Can you describe the purpose and semantics of the new dynamic tag in > textual form that doesn't refer to glibc functions and terms? I.e. > something that we can actually discuss on this mailing list? I can give it a shot, sure: The tricky part is that it really isn't necessary when you don't have namespaced DSO loading. But let's see if I can come up with something sensible. > I mean, we could just reserve value 0x6ffffdf4 with name DT_GNU_UNIQUE in > the GNU/Linux gABI and be done. But it seems saner to actually document > the intended semantics of it at the same place where it's reserved. That seems entirely reasonable. ------------------------------------------------------------------------- I should open by saying I originally implemented this as a new bitfield value for the payload of DT_FLAGS_1, but was told a new DT_GNU_… section might be more palatable/portable/less-conflict-prone. I have no axe to grind either way, both approaches work well for me. ------------------------------------------------------------------------- That said: The purpose of this tag is to mark DSOs which must be loaded no more than once by the dynamic loader. In normal use this is never a problem as the link chain is a simple linked list but when a partitioned loading scheme (such as the extra namespaces available via dlmopen(3) in glibc) is present it is possible for multiple copies of the same DSO to be resident. For DSOs which are "fundamental" in some way (eg libc.so, libpthread.so) the presence of a second copy can cause bizarre and difficult to debug problems. This tag hints to the linker/loader that the DSO should be present at most once, and requests (implicit or explicit) to load a segregated copy of it should NOT be honoured.