From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 102666 invoked by alias); 22 Oct 2019 11:18:06 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 102657 invoked by uid 89); 22 Oct 2019 11:18:06 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: EUR04-HE1-obe.outbound.protection.outlook.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6oFP+9QlWIUns3bRbBGibkLX3GXXtSIUE/BZWOb6PPE=; b=fVo3ecX2h2BpR5NSUKl/g7Pc9S4lncD5nZZcndJy/xGxkLycryJaeNRhrswICTSPh9baybLwmguS0Ajcf1M0wljPwTSPS+vcpzkGXjsDYyzfyBHhbamd+zrOa2i862QtVxsQymwmBzfCvHREaxUbogbyI8N3sqwLr1PNfDP2WwI= Authentication-Results: spf=temperror (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; sourceware.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;sourceware.org; dmarc=none action=none header.from=arm.com; Received-SPF: TempError (protection.outlook.com: error in processing during lookup of arm.com: DNS Timeout) X-CR-MTA-TID: 64aa7808 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Lo5/ELYqMUtCnRNtDDp2IJ0Bqf3qF/sVfAhGgnVIHM8nRJ5F56nP5YAC3xqnzytmxk+6OGY9dhAJgD1WpPEwfkfRdGSgaJyuLdGmsh5kuh1NmoqXqvuH41DIiRCXjamOJh3+2spC5R9QHO8COMfxaKwalbbyU6dXtuxmcBM+mcPyHmu7W1mxrQATnuwDlukZZcmzzCMz0A7LTWLhOaW/9GLAbX0j+tXbPMzLlPEf+eka/FWWrqgA+/+SfscNDa/9pBghvTktY40NDXjrFRYgTBt7mI/hY5kt9blGNdwYQLRb/kUg9sXlPkynFOPXRP5nrAIWA/5X8mYUDT1zTi1P+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6oFP+9QlWIUns3bRbBGibkLX3GXXtSIUE/BZWOb6PPE=; b=GsPncNvaV5JPELONrQewIlnWPJGe4A9IFfbKXAen/XruW2F2g8A3VZhzdMCAClN6k0lLwHrE4XRzvi30MCCJivXIV8Dz7X26iBibPQu3ZE5j88sSKIt9UcWf9PJJrZbkKhMt4UQjLkTGfQz+0pl8gF9eOzBZYMfePedn8yBJWZ2woZN/HHd9Ro7+cZlQw1YXJHPIXsW1DM1zXF5F0yvcN50KVe299R3p2cOeZJ3kBNKWn3SiDYPhN+udmlJ6GK6C4dFo294MWOCStn6WgWUc2iC5y27gAyg1mkXYPjqNhCcZyG8FJguw11EHOC1iKCU0pI/mRszS5GqprdNSW/pGXw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6oFP+9QlWIUns3bRbBGibkLX3GXXtSIUE/BZWOb6PPE=; b=fVo3ecX2h2BpR5NSUKl/g7Pc9S4lncD5nZZcndJy/xGxkLycryJaeNRhrswICTSPh9baybLwmguS0Ajcf1M0wljPwTSPS+vcpzkGXjsDYyzfyBHhbamd+zrOa2i862QtVxsQymwmBzfCvHREaxUbogbyI8N3sqwLr1PNfDP2WwI= From: David Kilroy To: Florian Weimer , Szabolcs Nagy CC: nd , "libc-alpha@sourceware.org" Subject: RE: [PATCH 1/3] elf: Allow dlopen of filter object to work [BZ #16272] Date: Tue, 22 Oct 2019 11:18:00 -0000 Message-ID: References: <4eae391688a6e42b0b75467de265c122e6402668.1571301957.git.david.kilroy@arm.com> <87r23ath25.fsf@oldenburg2.str.redhat.com> <87a79uqqxa.fsf@oldenburg2.str.redhat.com> <87imoinprn.fsf@oldenburg2.str.redhat.com> <6cbb4c5e-72e0-507d-fa34-5a70db35c03a@arm.com> <871rv5m7xu.fsf@oldenburg2.str.redhat.com> In-Reply-To: <871rv5m7xu.fsf@oldenburg2.str.redhat.com> x-ts-tracking-id: c00d315b-1215-4bd3-a068-d457e4c8be17.0 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=David.Kilroy@arm.com; x-ms-exchange-transport-forked: True x-checkrecipientrouted: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:9508; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM;SFS:(10009020)(4636009)(366004)(136003)(396003)(39860400002)(346002)(376002)(189003)(199004)(81156014)(3846002)(74316002)(81166006)(71200400001)(8676002)(71190400001)(6636002)(316002)(8936002)(54906003)(14454004)(66556008)(66946007)(7736002)(66476007)(64756008)(66446008)(305945005)(110136005)(33656002)(86362001)(2906002)(6116002)(5660300002)(52536014)(186003)(99286004)(446003)(256004)(476003)(6246003)(11346002)(26005)(229853002)(4326008)(76116006)(25786009)(478600001)(6436002)(486006)(7696005)(9686003)(102836004)(55016002)(76176011)(66066001)(6506007);DIR:OUT;SFP:1101;SCL:1;SRVR:AM0PR08MB4419;H:AM0PR08MB4068.eurprd08.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;MX:1;A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 3wGDpIi6t0zxzhTkkmD5AjidqewDP/J9C2Gkevg0Z4RL85wrI0bCbA11+W9PT+WxVtasMWRJT9StV6arAgLq+ibesxrW1nEXbzhJ9788BcGUCC3P449XafD4a8JbdLcdp3A6+KOT8A5qw1+GOdK/KlVB1/bRp6g4pafyb7NzZ1RQo81qsA5ydD4eiLeXqBl5qpOB1l88EdIIU6iqEo2eiRrlO9+gaiut+3SLNbSWqfdIEt9dykm3DbAhBqEsnxRgBh0Zk77SguExRgq2muQSJ1q4EVfbjxghzZgNWIvsK7Fk8EfsYZgF0Bb+OZJIAywc89OA5RcNG77hSIhgE8koAGxm3Gcz0MHbDKrISo3ML7WKSPI+vTFMclbuBWgsBYFyhYVtJM4RxjghL+yAD8nEplXnIB56nrkY7SRJ2hf0f5UOO2LUqczLFwEr3h0n76hv Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=David.Kilroy@arm.com; Return-Path: David.Kilroy@arm.com X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT037.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 8d6d32b9-9356-4889-c01f-08d756e1763a X-SW-Source: 2019-10/txt/msg00647.txt.bz2 > Florian Weimer >=20 > * Szabolcs Nagy: >=20 > > the scenario is: > > > > libA.so and libB.so export a set of symbols. this is abi and there > > are multiple providers of libA.so and libB.so. > > > > one provider wants to have a single libinternal.so that defines all > > the symbols of libA and libB as they share a lot of code. > > > > (1) having libA.so and libB.so as "wrapper libraries" around > > libinternal.so with RTLD_NEXT would work, but that's less efficient > > because of the extra indirection, >=20 > If libA.so and libB.so have libinternal.so as a DT_NEEDED dependency, > you do not need to implement forwarding with RTLD_NEXT. This is possible. You still need wrapper functions of some form. You can try to avoid them by defining libA with no symbols and DT_NEEDED libinternal.so, but then you need to link with -Wl,--copy-dt-needed (BFD only) and end up with a dependency on libinternal.so rather than libA.so. > > (3) symlinking libA.so and libB.so to libinternal.so makes all > symbols > > visible when either of them is loaded, polluting the link namespace. >=20 > Filters do that as well. There is no actual per-symbol run-time > filtering implemented today, and it is unclear if Solaris implements it. Agreed. =20 > > (libinternal.so is a video driver lib and libA, libB, .. are various > > opengl libs with fixed abi) >=20 > Is there an expectation that libinternal interposes symbols in libA > etc., perhaps with more efficient implementations? And if not, a > fallback implementation in libA etc. is used? This is clearly not > supported by the Solaris filter feature (as documented). I'm not sure what you mean here. Libinternal.so is expected to supply the implementations for the symbols in libA.so. Ideally we wouldn't pick up other symbols from libinternal, but this is not an issue for us. If libinternal.so were to use IFUNC relocations for libA's symbols, I would hope it works, but I don't think that's being done. Thanks, Dave.