| Message ID | 20171029211541.GA6435@gmail.com |
|---|---|
| State | New, archived |
| Headers |
Received: (qmail 16290 invoked by alias); 29 Oct 2017 21:15:48 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 16271 invoked by uid 89); 29 Oct 2017 21:15:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.4 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM, SPF_PASS autolearn=ham version=3.3.2 spammy=H*M:20171029211541, H*MI:20171029211541 X-HELO: mail-pg0-f46.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=3r62ncGZWZsOGsrlJ2UQXpSFiMfW1nyWC3CogxZ2lpQ=; b=WJNj5Mev7jExIB11VV45qakw3lbYMmCc+Q+saw7OqFIA3U/lLVRNSgHmLuFrRZO/jv xKggr/OJj8/+2kVdauqeLt3QNsnOmK69UYKTHTGqltPCsxtYGTxkOnyBVWAJf0h0+zXC shmcc+QDSsit/RXCuzT4Pvj8WqqJDdqmpdjmmh9NZlavBcLEQDKWZaebYoflMSIPF0cA uohSoxIw6IgafqJEJx7+sRdl8LwWJoAnV01Z0PsqkgdGT/e9UU7EXqQfMDZTa4N1tibv NLX9kzo1Z6NhjVQwwJO/Q1ODfGEj12l7Zi9bxhaDbzfb6ROm1W3D+i3trUAnjmb0miEf dAjg== X-Gm-Message-State: AMCzsaXJbAUg26lUqqLwM3ZEYBxjkgg7pEer1jhVgv5L23lcgf+f2Chc StCkqZJvUDaXwgmNyxQSx1kzrA== X-Google-Smtp-Source: ABhQp+Q5V1vJ58gtWAVWgi+jp8rInQ679LBiukVWYwi1rFN8EpdiYGyWE2Q+I110bIoUHgMK1HRu/g== X-Received: by 10.99.99.71 with SMTP id x68mr6024442pgb.334.1509311742691; Sun, 29 Oct 2017 14:15:42 -0700 (PDT) Date: Sun, 29 Oct 2017 14:15:41 -0700 From: "H.J. Lu" <hjl.tools@gmail.com> To: GNU C Library <libc-alpha@sourceware.org> Subject: [PATCH] x32: Set GLRO(dl_platform) to "x86_64" by default [BZ #22363] Message-ID: <20171029211541.GA6435@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.1 (2017-09-22) |
Commit Message
H.J. Lu
Oct. 29, 2017, 9:15 p.m. UTC
Set dl_platform to "x86_64" for x32 by default since kernel may set it to "i686". This fixed: FAIL: elf/tst-platform-1 on x32. Tested on x86-64 and x32. Any comments? H.J. --- [BZ #22363] * sysdeps/x86/cpu-features.c (init_cpu_features): Set GLRO(dl_platform) to "x86_64" by default for x32. --- sysdeps/x86/cpu-features.c | 5 +++++ 1 file changed, 5 insertions(+)
Comments
On Okt 29 2017, "H.J. Lu" <hjl.tools@gmail.com> wrote: > Set dl_platform to "x86_64" for x32 by default since kernel may set it > to "i686". Why does it do that? Isn't that a kernel bug? Andreas.
On 10/30/2017 08:05 AM, Andreas Schwab wrote: > On Okt 29 2017, "H.J. Lu" <hjl.tools@gmail.com> wrote: > >> Set dl_platform to "x86_64" for x32 by default since kernel may set it >> to "i686". > > Why does it do that? Isn't that a kernel bug? The whole thing is a bit iffy. Why does the kernel set AT_PLATFORM to i686 when running on a x86_64 machine? x86_64 would make more sense because it allows the loader to select libraries which were compiled with -march=x86-64. I think AT_PLATFORM should be about CPU capabilities, not the initial CPU mode after process creation. The latter requires separate search paths anyway. Thanks, Florian
On Mon, Oct 30, 2017 at 12:05 AM, Andreas Schwab <schwab@linux-m68k.org> wrote: > On Okt 29 2017, "H.J. Lu" <hjl.tools@gmail.com> wrote: > >> Set dl_platform to "x86_64" for x32 by default since kernel may set it >> to "i686". > > Why does it do that? Isn't that a kernel bug? > There is include/asm/elf.h:#define COMPAT_ELF_PLATFORM ("i686") It is much simpler to fix it in glibc.
On Mon, Oct 30, 2017 at 2:47 AM, Florian Weimer <fweimer@redhat.com> wrote: > On 10/30/2017 08:05 AM, Andreas Schwab wrote: >> >> On Okt 29 2017, "H.J. Lu" <hjl.tools@gmail.com> wrote: >> >>> Set dl_platform to "x86_64" for x32 by default since kernel may set it >>> to "i686". >> >> >> Why does it do that? Isn't that a kernel bug? > > > The whole thing is a bit iffy. Why does the kernel set AT_PLATFORM to i686 > when running on a x86_64 machine? x86_64 would make more sense because it Before x32 has 32-bit address space, it uses include/asm/elf.h:#define COMPAT_ELF_PLATFORM ("i686") It is correct for i386 program, but incorrect for x32 program. > allows the loader to select libraries which were compiled with > -march=x86-64. I think AT_PLATFORM should be about CPU capabilities, not > the initial CPU mode after process creation. The latter requires separate > search paths anyway. > The whole AT_PLATFORM was useful before we implemented early CPUID check in glibc.
On Okt 30 2017, "H.J. Lu" <hjl.tools@gmail.com> wrote: > On Mon, Oct 30, 2017 at 12:05 AM, Andreas Schwab <schwab@linux-m68k.org> wrote: >> On Okt 29 2017, "H.J. Lu" <hjl.tools@gmail.com> wrote: >> >>> Set dl_platform to "x86_64" for x32 by default since kernel may set it >>> to "i686". >> >> Why does it do that? Isn't that a kernel bug? >> > > There is > > include/asm/elf.h:#define COMPAT_ELF_PLATFORM ("i686") > > It is much simpler to fix it in glibc. Take a look how this is solved for aarch64 ILP32. Andreas.
On Mon, Oct 30, 2017 at 9:28 AM, Andreas Schwab <schwab@linux-m68k.org> wrote: > On Okt 30 2017, "H.J. Lu" <hjl.tools@gmail.com> wrote: > >> On Mon, Oct 30, 2017 at 12:05 AM, Andreas Schwab <schwab@linux-m68k.org> wrote: >>> On Okt 29 2017, "H.J. Lu" <hjl.tools@gmail.com> wrote: >>> >>>> Set dl_platform to "x86_64" for x32 by default since kernel may set it >>>> to "i686". >>> >>> Why does it do that? Isn't that a kernel bug? >>> >> >> There is >> >> include/asm/elf.h:#define COMPAT_ELF_PLATFORM ("i686") >> >> It is much simpler to fix it in glibc. > > Take a look how this is solved for aarch64 ILP32. > I saw #define ELF_PLATFORM ("aarch64_be") #define ELF_PLATFORM ("aarch64") #define COMPAT_ELF_PLATFORM ("v8b") #define COMPAT_ELF_PLATFORM ("v8l") on staging/ilp32-4.13 branch. I assume v8l/v8b will be used as AT_PLATFORM for both ILP32 and arm32 programs. I don't see how this approach can work for i686 and x32.
On 10/30/2017 07:15 PM, H.J. Lu wrote: > I saw > > #define ELF_PLATFORM ("aarch64_be") > #define ELF_PLATFORM ("aarch64") > #define COMPAT_ELF_PLATFORM ("v8b") > #define COMPAT_ELF_PLATFORM ("v8l") > > on staging/ilp32-4.13 branch. > > I assume v8l/v8b will be used as AT_PLATFORM for both ILP32 and > arm32 programs. I don't see how this approach can work for i686 > and x32. The bug is that with an x86-64 kernel, we didn't set AT_PLATFORM to x86_64 by default for all executables because that's a reasonable way to identify the microarchitecture (in particular, that there is SSE2 support, and you can switch to long mode if you think it's beneficial for what you are doing). Thanks, Florian
On Okt 30 2017, "H.J. Lu" <hjl.tools@gmail.com> wrote: > I assume v8l/v8b will be used as AT_PLATFORM for both ILP32 and > arm32 programs. $ LD_SHOW_AUXV=1 /usr/bin/true AT_SYSINFO_EHDR: 0xf7e0e000 AT_HWCAP: 8ff AT_PAGESZ: 4096 AT_CLKTCK: 100 AT_PHDR: 0x9ea034 AT_PHENT: 32 AT_PHNUM: 9 AT_BASE: 0xf7dd0000 AT_FLAGS: 0x0 AT_ENTRY: 0x9eb460 AT_UID: 0 AT_EUID: 0 AT_GID: 0 AT_EGID: 0 AT_SECURE: 0 AT_RANDOM: 0xffcfa0a2 AT_HWCAP2: 0x0 AT_EXECFN: /usr/bin/true AT_PLATFORM: aarch64:ilp32 Andreas.
On Mon, Oct 30, 2017 at 11:36 AM, Andreas Schwab <schwab@linux-m68k.org> wrote: > On Okt 30 2017, "H.J. Lu" <hjl.tools@gmail.com> wrote: > >> I assume v8l/v8b will be used as AT_PLATFORM for both ILP32 and >> arm32 programs. > > $ LD_SHOW_AUXV=1 /usr/bin/true > AT_SYSINFO_EHDR: 0xf7e0e000 > AT_HWCAP: 8ff > AT_PAGESZ: 4096 > AT_CLKTCK: 100 > AT_PHDR: 0x9ea034 > AT_PHENT: 32 > AT_PHNUM: 9 > AT_BASE: 0xf7dd0000 > AT_FLAGS: 0x0 > AT_ENTRY: 0x9eb460 > AT_UID: 0 > AT_EUID: 0 > AT_GID: 0 > AT_EGID: 0 > AT_SECURE: 0 > AT_RANDOM: 0xffcfa0a2 > AT_HWCAP2: 0x0 > AT_EXECFN: /usr/bin/true > AT_PLATFORM: aarch64:ilp32 > > Andreas. > arm64 uses arch/arm64/kernel/binfmt_ilp32.c:#undef ELF_PLATFORM arch/arm64/kernel/binfmt_ilp32.c:#define ELF_PLATFORM ("aarch64_be:ilp32") arch/arm64/kernel/binfmt_ilp32.c:#define ELF_PLATFORM ("aarch64:ilp32") Let me ask x86 kernel people.
diff --git a/sysdeps/x86/cpu-features.c b/sysdeps/x86/cpu-features.c index 87aaa8683c..0ca29365ef 100644 --- a/sysdeps/x86/cpu-features.c +++ b/sysdeps/x86/cpu-features.c @@ -430,6 +430,11 @@ no_cpuid: if (platform != NULL) GLRO(dl_platform) = platform; +# ifdef __ILP32__ + /* Set dl_platform to "x86_64" since kernel may set it to "i686". */ + else + GLRO(dl_platform) = "x86_64"; +# endif } #else GLRO(dl_hwcap) = 0;