From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127692 invoked by alias); 12 Sep 2018 15:34:49 -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 127680 invoked by uid 89); 12 Sep 2018 15:34:49 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=speaking X-HELO: mail-qt0-f194.google.com MIME-Version: 1.0 References: <53924daa4b51c0d552d17d3c5fd9aea09f9fc4b2.1536720821.git.han_mao@c-sky.com> In-Reply-To: From: Arnd Bergmann Date: Wed, 12 Sep 2018 15:34:00 -0000 Message-ID: Subject: Re: [PATCH v4 06/13] C-SKY: Linux ABI To: Joseph Myers Cc: Mao Han , GNU C Library , c-sky_gcc_upstream@c-sky.com, gnu-csky@mentor.com Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-09/txt/msg00162.txt.bz2 On Wed, Sep 12, 2018 at 5:18 PM Joseph Myers wrote: > > On Wed, 12 Sep 2018, Arnd Bergmann wrote: > > > I'm surprised to see copies of bits/shm.h, bits/mman.h and sys/procfs.h. > > Since the kernel port just uses the generic interfaces that all other > > architectures used in the past decade, shouldn't the glibc defaults > > match be enough here? > > There's no generic bits/mman.h for systems using the Linux kernel; a lot > is shared through bits/mman-linux.h and bits/mman-shared.h, but all > architectures need their own bits/mman.h as well. Ok. I checked a couple that should be using the generic kernel implementation and found that at least nios2, aarch64 and riscv differ only in comments, so this is probably something that can be improved by creating a common version. > In practice there's no generic sys/procfs.h either > (sysdeps/unix/sysv/linux/sys/procfs.h exists but all architectures > override it - so if there's something in common between many architectures > such that they don't need their own files, it's quite likely that file > does not reflect whatever is common). This one seems worse: looking at the same architectures above, I find that at least nios2 is wrong: pr_uid/pr_gid are declared as 'unsigned short' here, compat to a signed 'long int' for riscv and 'unsigned int' for aarch64. In the kernel, these are all 'unsigned int' except on some older 32-bit architectures (arm, m68k, s390-32, sh, sparc32, sparc64, and x86-32). Aside from that, they are basically identical, except for the regset array types that match the number of registers. Speaking of this file, I think we still need a solution for elf_prstatus containing a 'timeval' after time_t becomes 64-bit wide. I actually have a patch to change the kernel header file declaring the same structure, but I had not realized that glibc contains another copy. https://sourceware.org/glibc/wiki/Y2038ProofnessDesign mentions that type, but not what to do about it. What I did in the kernel was to change the type of pr_utime/pr_stime/pr_cutime/pr_cstime to something that keeps using 'long' fields. Given that we can't change the file format in an incompatible way, and that 32-bit is sufficient here, that seemed like the most appropriate solution. Arnd