This is the mail archive of the
mailing list for the glibc project.
Re: Fix sys/procfs.h pr_uid, pr_gid type (bug 23649)
- From: Arnd Bergmann <arnd at arndb dot de>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 14 Sep 2018 13:30:26 +0200
- Subject: Re: Fix sys/procfs.h pr_uid, pr_gid type (bug 23649)
- References: <alpine.DEB.email@example.com>
On Thu, Sep 13, 2018 at 10:49 PM Joseph Myers <firstname.lastname@example.org> wrote:
> As noted in
> <https://sourceware.org/ml/libc-alpha/2018-09/msg00178.html>, glibc's
> sys/procfs.h headers for microblaze, mips (n64), nios2 and riscv have
> incorrect types for the pr_uid and pr_gid members of struct
> elf_prpsinfo (as does the generic Linux version, but nothing uses
> This patch fixes those headers to use unsigned int. The generic Linux
> version is also fixed, but I do *not* recommend making new
> architectures use it yet. Rather, I think it should be reworked to
> look more like a copy of the AArch64 version, but with a new
> <bits/procfs.h> header included to provide register set definitions;
> <bits/procfs.h> would then be architecture-specific while many
> architectures could use the generic <sys/procfs.h>. This fix is
> deliberately separate from any reworking to use a generic header more,
> since it's possible there could be uses for backporting this fix but
> not for backporting a subsequent cleanup.
> Tested with build-many-glibcs.py. This of course doesn't provide much
> validation of the structure layout; if the Linux kernel is fixed so
> that "#include <linux/elfcore.h>" actually compiles with the headers
> from "make headers_install" (and if the layout in both headers is
> meant to be the same, whatever ABI we are building for), I have a test
> that can be added to glibc to check the layout against that from the
> Linux kernel.
> 2018-09-13 Joseph Myers <email@example.com>
Looks all good to me, thanks for addressing this!
I've had a look at including linux/elfcore.h from user space,
and what it would take to get it working again. I've got a
prototype patch now (x86 only) that I'll post for futher discussion.