From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53538 invoked by alias); 28 Apr 2017 14:44:07 -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 52552 invoked by uid 89); 28 Apr 2017 14:44:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=fweimer@redhat.com, sk:fweimer, U*fweimer, fweimerredhatcom X-HELO: mail-qt0-f176.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nuoC9K98Vsl+u6yDX/TMGxdLXoDb8cdQu0KRHmPtj4o=; b=g0+9e0u4IjBWS2JgnvmknUjKxznwMR3o64FkQ+pVJA1lVYRUMzTqbFkoW8esm0nya6 OTHM7zFSYeF0tWhJE+EjrGO4EWRiSLNIqkWPBap97yGS21BztCJvciigC2lggUJ0NBT4 yRwk062Lik8oGzwViAF5xpFkpbTOT5Ah0gioK703QUCdpJllLhglZPWsXW+6HeYa+6Pt Zt6DnpPjkf9CPRj+QcW1Gw71CZGvbbMpQ2JDFzSm5MU5O8mZS2a+0msodqy4cCvTitYd IRRYHuiK2N3rNRZHqOupHpQDsfDEW7P/DF2uixwgpJ3SYOGTqwRC9Qmfg9V91kFclUVk dm9w== X-Gm-Message-State: AN3rC/6jASnDfVx1QwPl2lrDcXmdRmesHgkfNnAESdAteMh+oV5Nb2fG 5J9t5ynQdY2F3t6l9BwCcyL0aRUgRg== X-Received: by 10.237.50.197 with SMTP id z63mr10214107qtd.48.1493390645614; Fri, 28 Apr 2017 07:44:05 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20170419183532.GA18407@intel.com> <792761c6-5f72-cadf-eb94-9fa408d111b3@redhat.com> From: "H.J. Lu" Date: Fri, 28 Apr 2017 14:44:00 -0000 Message-ID: Subject: Re: [PATCH] [BZ #21391] x86: Set dl_platform and dl_hwcap from CPU features To: Florian Weimer Cc: GNU C Library Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2017-04/txt/msg00559.txt.bz2 On Thu, Apr 20, 2017 at 7:42 AM, H.J. Lu wrote: > On Thu, Apr 20, 2017 at 1:51 AM, Florian Weimer wrote: >> On 04/19/2017 09:31 PM, H.J. Lu wrote: >>> >>> On Wed, Apr 19, 2017 at 12:02 PM, Florian Weimer >>> wrote: >>>> >>>> On 04/19/2017 08:35 PM, H.J. Lu wrote: >>>>> >>>>> >>>>> dl_platform and dl_hwcap are set from AT_PLATFORM and AT_HWCAP very >>>>> early during startup. They are used by dynamic linker to determine >>>>> platform and build an array of hardware capability names, which are >>>>> added to search path when loading shared object. dl_platform and >>>>> dl_hwcap are unused on x86-64. On i386, i386, i486, i586 and i686 >>>>> platforms were supported and only SSE2 capability was used. >>>> >>>> >>>> >>>> I don't know where you want to take this, so it's hard to tell if this is >>>> going to cause problems eventually. GLRO is default-initialized in a >>>> nested >>>> libc (after dlmopen or static dlopen). >>>> >>> >>> dl_platform and dl_hwcap are used to search for additional directories >>> when >>> loading a shared object: >>> >>> 15453: find library=libx.so [0]; searching >>> 15453: search path=./tls/x86_64:./tls:./x86_64:. (RPATH from file >>> ./m) >>> 15453: trying file=./tls/x86_64/libx.so >>> 15453: trying file=./tls/libx.so >>> 15453: trying file=./x86_64/libx.so >>> 15453: trying file=./libx.so >>> 15453: >>> >>> My change updates them inside dynamic linker before they are used >>> by dynamic linker. On Haswell class machines, I got >>> >>> 19268: find library=libx.so [0]; searching >>> 19268: search path=./tls/haswell:./tls:./haswell:. (RPATH from file >>> ./m) >>> 19268: trying file=./tls/haswell/libx.so >>> 19268: trying file=./tls/libx.so >>> 19268: trying file=./haswell/libx.so >>> >>> When loading libx.so, it prefers the one in the "haswell" subdirectory. >>> One can place shared libraries optimized for Haswell class processors >>> under the "haswell" subdirectory. They will be used on Haswell class >>> processors. It has no impact on static dlopen nor nested libc. >> >> >> Okay, but only because the external dynamic linker is used, which has a >> fully set up GLRO object. The default-initialized GLRO object in the inner >> libc is not used in this case. > > That is true. My patch only applies to the external dynamic linker. > Any other comments? -- H.J.