From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116702 invoked by alias); 22 Oct 2019 11:27:56 -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 116683 invoked by uid 89); 22 Oct 2019 11:27:56 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=AWL,BAYES_00,FORGED_SPF_HELO,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=no 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=l/+SqTA15f4tf4hch8Hc7hP2gj6deQzp42CXIlmtDGA=; b=5j4dG5TFcvO5245GEvCtYc2+uy4CKWIt2goMoR6mL8ehd/z1/2ee7wHVeHMPmd1/Jgod0Ww/noCz77ab3UAmCmbNP3iSdS7a7M+TqFQi9iNPmZ0PpCfhW9c7CHoCADNfBpVtjdoOdsy4Xg+DhDNYbsrf4aRiLHbhZ4/L8n2rCxg= 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=NeDJmjmKLXZ8p0GAfMUfVldtktaiCOEWYbMPw68vgJe/1ol2GQFd3zX6nBOshcojyaHBUxV/OPxH6iEt6/i7oqnTkczNAz/3i9BO9DNSb87bX653sWZDg63vuPs2K3O3BlXnQwoItiF/bBbkX2aR8CAO7v8/tWIfJG6KNuxdfQnZkGqQG/6emyVQUi+LvX0bOIwONAGE5WflzYCb/CjVi74rjvExv/5PfRZdq3A5OH+j3F/uFz/KSI6nqPmTlLIFgTI2R8r/za0/Tvcz17y1L+DM0tTPNm1ECTuVqyJ6IwODGHPnBkojAlqwJTi4H1g4MyVvoFVBOOpAvmgoNvboIA== 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=l/+SqTA15f4tf4hch8Hc7hP2gj6deQzp42CXIlmtDGA=; b=Es/ii+mL6JPZs+lDS6SE7b7hDXvoVl7iqLdUSFRmdT8qzHNnAoZtx+xigR3FP4Xu8p+56UEjsMDbMgMWLVBDsnZfTmTWk2aTY4is5KUhvkwnwvFanfI3+OtNNIACH3hqV8G23WciS+vCRPYwRuaob9NistJBqJ7LtO5xmR4XaEsQkE/SfBoanrtMQsgbwT+B7fcsk34PYweTvLcSbm5EylqOWjj5enNn+jMU119fHOVnx89ySjJFjT0frdcW7wWxTekmqaza5xN7Kz+QkZoOk8wfG2ZF0CGioZleH8Y6aWSBKHNZ6GdVQ7hfAzTA+2zTmiaXutrDQMG2GdizuNcrtA== 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=l/+SqTA15f4tf4hch8Hc7hP2gj6deQzp42CXIlmtDGA=; b=5j4dG5TFcvO5245GEvCtYc2+uy4CKWIt2goMoR6mL8ehd/z1/2ee7wHVeHMPmd1/Jgod0Ww/noCz77ab3UAmCmbNP3iSdS7a7M+TqFQi9iNPmZ0PpCfhW9c7CHoCADNfBpVtjdoOdsy4Xg+DhDNYbsrf4aRiLHbhZ4/L8n2rCxg= From: David Kilroy To: Florian Weimer CC: Szabolcs Nagy , 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:27: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> <87k18xkosk.fsf@oldenburg2.str.redhat.com> In-Reply-To: <87k18xkosk.fsf@oldenburg2.str.redhat.com> x-ts-tracking-id: 419a71d7-face-4104-8760-b59599406bb1.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:10000;OLM:10000; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM;SFS:(10009020)(4636009)(346002)(136003)(376002)(39860400002)(396003)(366004)(199004)(189003)(256004)(446003)(186003)(26005)(102836004)(11346002)(6506007)(76176011)(486006)(476003)(66066001)(7696005)(52536014)(316002)(5660300002)(478600001)(54906003)(14454004)(71190400001)(71200400001)(25786009)(305945005)(74316002)(8936002)(81166006)(81156014)(86362001)(8676002)(7736002)(229853002)(4326008)(6246003)(99286004)(3846002)(2906002)(64756008)(55016002)(9686003)(66446008)(76116006)(66946007)(66476007)(66556008)(6916009)(6116002)(6436002)(33656002);DIR:OUT;SFP:1101;SCL:1;SRVR:AM0PR08MB4164;H:AM0PR08MB4068.eurprd08.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX: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: qvKGtdQbpZa0fbAv9afR0bQIThBovSxiChfG4b0ClPrVGFSBUAbSxpdTZJblCx+PwEWVu38gwYQpvhKf4jrpF5fqh/387ngkpdzE1QV+jrlAn2lUq8PJDrd19wkLhmKBuu7ivppphsm0MyFRr16QJ9jLBLQbR1FkLQcX/UxqVZ5fd9HPLUxVDkU+/v+lKcM2SIFTdX8uoeA5UwJHRlk14yP01o0OSxlpwSDFdHiiBfkoqiAezk/HhtkUWMENiTYqjVz8+ujhbKEu1QeohMbRAXg7G9VYvxgp8crQTd1lvvqKqEKqMDxT5TB/jBY39C/3G+u7OWGgYoS748GqXVsLXA6u5DCgL2z+XA93Ypt22tfQf9VMW/4RwOnOuV4nyQm7VwFed6TQXnzwB7aRT1TAclJLZqfUKDVlxJPDvAXU1zNQYGKMszqg2udyeMm35xip 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: VE1EUR03FT026.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 041aecd8-f299-49d8-07b1-08d756e2d8e2 X-SW-Source: 2019-10/txt/msg00651.txt.bz2 > Florian Weimer >=20 > * David Kilroy: >=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. >=20 > I mean something like this. libA defines f1, f2, f3. libinternal > replaces f1 and f3 with optimized implementations, but not f2. > Applications which call f2 are expected to get the unoptimized > implementation in f2. Ah, no we don't do that. Our filter libraries would only contains stubs. The real implementation for all functions would live in libinternal.so. Thanks, Dave.