This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH v4 06/13] C-SKY: Linux ABI
On Wed, Sep 12, 2018 at 5:18 PM Joseph Myers <email@example.com> 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
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
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.