This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: struct elf_prstatus and Y2038 (was: Re: [PATCH v4 06/13] C-SKY: Linux ABI)
On Wed, Sep 12, 2018 at 11:28 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> On 09/12/2018 05:34 PM, Arnd Bergmann wrote:
> > 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.
>
> Keeping 32 bits there looks reasonable. I thought we had a port where
> time_t isn't long, but that doesn't seem to be the case.
Ok. I'll change it to 'struct __kernel_old_timeval' in the kernel
headers then, keeping the existing definition we have for timeval.
I did that patch a while ago, but think I've never posted it
for inclusion so far.
The same thing also gets used in the implementation for
the wait4()/waitid() and getrusage() syscalls, which carry the same
data as the core file, as well as the various VDSO implementations
that we can't change over.
I'm still undecided on whether we want a version of waitid and
getrusage that takes a 64-bit timespec or 64-bit timeval
for consistency, or just let the libc deal with the conversion from
the 32-bit timeval here.
> Ah, I think it's actually s390, where suseconds_t is int, not long.
Odd: in the kernel, suseconds_t is long on s390, but int on
sparc and parisc. Were you thinking of sparc64 instead of s390
maybe? I would guess that parisc64 is actually wrong here, but
since there are not a lot of users on parisc and they tend to run
32-bit user space, it's plausible that this never got caught.
I totally missed the sparc/parisc oddity about suseconds_t
in the past, I'll have to modify my patch for that.
Arnd