public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Florian Weimer <fweimer@redhat.com>
Cc: Joseph Myers <joseph@codesourcery.com>,
	Mao Han <han_mao@c-sky.com>,
	 GNU C Library <libc-alpha@sourceware.org>,
	c-sky_gcc_upstream@c-sky.com,  gnu-csky@mentor.com
Subject: Re: struct elf_prstatus and Y2038 (was: Re: [PATCH v4 06/13] C-SKY: Linux ABI)
Date: Thu, 13 Sep 2018 10:48:00 -0000	[thread overview]
Message-ID: <CAK8P3a0QoOzbQG95zz4cUJ5=-kfNDVop03kR5cnv1PA1OWX93w@mail.gmail.com> (raw)
In-Reply-To: <9466b02a-ddca-9baf-c9b5-83d06af3a5fa@redhat.com>

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

  reply	other threads:[~2018-09-13 10:48 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-12  2:56 [PATCH v4 00/13] port C-SKY to glibc Mao Han
     [not found] ` <cover.1536720821.git.han_mao@c-sky.com>
2018-09-12  2:56   ` [PATCH v4 05/13] C-SKY: Linux Syscall Interface Mao Han
2018-09-12  2:56   ` [PATCH v4 01/13] C-SKY: ABI related code Mao Han
2018-09-12  4:16     ` H.J. Lu
2018-09-12  7:07       ` Mao Han
2018-09-12  8:23         ` Florian Weimer
2018-09-12  9:06           ` Mao Han
2018-09-29  1:46           ` Palmer Dabbelt
2018-09-30  9:04             ` Manuel A. Fernandez Montecelo
2018-10-01  8:18             ` Richard W.M. Jones
2018-09-17 21:46     ` Joseph Myers
2018-09-18  6:09       ` Mao Han
2018-09-12  2:56   ` [PATCH v4 03/13] C-SKY: Math support Mao Han
2018-09-17 21:49     ` Joseph Myers
2018-09-18  6:05       ` Mao Han
2018-09-12  2:56   ` [PATCH v4 02/13] C-SKY: TLS support Mao Han
2018-09-12  2:57   ` [PATCH v4 08/13] C-SKY: Linux Startup and Dynamic Loading Code Mao Han
2018-09-12  2:57   ` [PATCH v4 13/13] C-SKY: Skeleton documentation Mao Han
2018-09-12  2:57   ` [PATCH v4 06/13] C-SKY: Linux ABI Mao Han
2018-09-12 13:40     ` Arnd Bergmann
2018-09-12 14:21       ` Joseph Myers
2018-09-12 15:34         ` Arnd Bergmann
2018-09-12 21:28           ` struct elf_prstatus and Y2038 (was: Re: [PATCH v4 06/13] C-SKY: Linux ABI) Florian Weimer
2018-09-13 10:48             ` Arnd Bergmann [this message]
2018-09-13 10:56               ` struct elf_prstatus and Y2038 Florian Weimer
2018-09-13  8:17       ` [PATCH v4 06/13] C-SKY: Linux ABI Mao Han
2018-09-13  8:46         ` Arnd Bergmann
2018-09-13 15:32           ` [gnu-csky] " Joseph Myers
2018-09-13 16:35             ` Joseph Myers
2018-09-13 20:47               ` Arnd Bergmann
2018-09-13 20:59                 ` Joseph Myers
2018-09-13 21:32                   ` Arnd Bergmann
2018-09-13 22:57                     ` Joseph Myers
2018-09-13 20:31             ` Arnd Bergmann
2018-09-13 20:49               ` Joseph Myers
2018-09-13 21:38                 ` Arnd Bergmann
2018-09-12  2:57   ` [PATCH v4 12/13] C-SKY: Add build-many-glibcs.py support Mao Han
2018-09-12  2:57   ` [PATCH v4 09/13] C-SKY: Add dynamic relocations to elf.h Mao Han
2018-09-12  2:57   ` [PATCH v4 11/13] C-SKY: Add ABI definitions in config.h.in Mao Han
2018-09-12  3:05   ` [PATCH v4 07/13] C-SKY: ABI Lists Mao Han
2018-09-12  6:51     ` Andreas Schwab
2018-09-12  7:12       ` Mao Han
2018-09-12 12:35       ` Joseph Myers
2018-09-12 13:46         ` Andreas Schwab
2018-09-12 15:19           ` Joseph Myers
2018-09-13  8:23         ` Mao Han
2018-09-12  3:05   ` [PATCH v4 04/13] C-SKY: NPTL support and Atomic Mao Han
2018-09-12  3:05   ` [PATCH v4 10/13] C-SKY: Build Infastructure Mao Han
2018-09-17 21:52     ` Joseph Myers
2018-09-18  6:02       ` Mao Han
2018-09-12  3:05 ` [PATCH 1/1] Update config.guess and config.sub to current versions Mao Han
2018-09-12 12:31 ` [PATCH v4 00/13] port C-SKY to glibc Joseph Myers
2018-09-13  8:14   ` Mao Han
2018-09-13 12:36     ` Joseph Myers
2018-09-18  6:22       ` Mao Han
2018-09-18  7:18         ` Mao Han
2018-09-18 11:43           ` Joseph Myers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAK8P3a0QoOzbQG95zz4cUJ5=-kfNDVop03kR5cnv1PA1OWX93w@mail.gmail.com' \
    --to=arnd@arndb.de \
    --cc=c-sky_gcc_upstream@c-sky.com \
    --cc=fweimer@redhat.com \
    --cc=gnu-csky@mentor.com \
    --cc=han_mao@c-sky.com \
    --cc=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).