public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: YunQiang Su <wzssyqa@gmail.com>
To: Jonathan Wakely <jwakely@redhat.com>
Cc: Chen Li <chenli@uniontech.com>,
	libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] skip testing time before epoch on mips
Date: Mon, 8 Mar 2021 19:15:19 +0800	[thread overview]
Message-ID: <CAKcpw6U8g1GExXC0yHN-3SYgy0GbEYbft72N3=1-yUXBy2WETA@mail.gmail.com> (raw)
In-Reply-To: <YEYDKszusKrcZWLC@redhat.com>

Jonathan Wakely via Gcc-patches <gcc-patches@gcc.gnu.org> 于2021年3月8日周一 下午6:57写道:
>
> On 08/03/21 14:35 +0800, Chen Li wrote:
> >
> >When execute libstdc++ testcases on mips, I notice that last_write_time
> >alawys failed, and the failed VERIFY is  "VERIFY(
> >approx_equal(last_write_time(f.path), time) );" where testing time before
> >than epoch.
> >
> >Below is the minimal case:
> >
> >```
> >// gcc a.c
> >int main()
> >{
> >        struct timespec times[2] = {{1, UTIME_OMIT}, {-1201, 985000000}};
> >        utimensat(AT_FDCWD, "test", times, 0);
> >
> >}
> >```
> >
> >$ touch test && gcc a.c && ./a.out && stat test
> >  File: test
> >  Size: 0               Blocks: 0          IO Block: 4096   regular empty file
> >Device: 805h/2053d      Inode: 1056841     Links: 1
> >Access: (0644/-rw-r--r--)  Uid: ( 1000/  deepin)   Gid: ( 1000/  deepin)
> >Access: 2021-03-08 13:52:55.966354501 +0800
> >Modify: 2106-02-07 14:08:15.985000000 +0800
> >Change: 2021-03-08 13:52:56.907782193 +0800
> > Birth: -
> >
> >Undoubtedly, mtime's type is unsigned somewhere on mips.
> >
> >After debuging kernel, it turns out that mtime is always -1201 in
> >ext4_setattr, cp_new_stat, newlstat and etc, so the problem should not
> >occur in kernel space.
> >
> >go back to user space via copy_to_user, I finally found mips used
> >"unsigned int st_mtime_sec;" in struct kernel_stat, which is used to
> >receive -1201 from kernel.
>
> I can't reproduce this on a mips64 machine:
>
> jwakely@erpro8-fsf2:~$ uname -a
> Linux erpro8-fsf2 4.1.4 #1 SMP PREEMPT Mon Aug 3 14:22:54 PDT 2015 mips64 GNU/Linux
> jwakely@erpro8-fsf2:~$ apt list libc6
> Listing... Done
> libc6/oldstable,now 2.19-18+deb8u10 mipsel [installed]

it is mips32, not mips64. Here mips64 we mean userland, not the kernel.

> jwakely@erpro8-fsf2:~$ touch test && ./a.out && TZ= stat test
>    File: ‘test’
>    Size: 0               Blocks: 0          IO Block: 131072 regular empty file
> Device: 21h/33d Inode: 36596524    Links: 1
> Access: (0644/-rw-r--r--)  Uid: ( 1049/ jwakely)   Gid: ( 1049/ jwakely)
> Access: 2021-03-08 10:52:06.855991946 +0000
> Modify: 1969-12-31 23:39:59.985000000 +0000
> Change: 2021-03-08 10:52:06.859992051 +0000
>   Birth: -
>
> This is an ext4 filesystem.
>
> Do I need to compile a 64-bit executable?
>

Yes. you need 64bit userland.

> In any case, shouldn't this be fixed in glibc to return EINVAL instead
> of setting a bogus time? That would make the std::filesystem library
> report an error.
>

Since kernel has introduced statx(2), so we can use statx to implemente stat(3).

>
> >Maybe sparc also suffers from this problem, but I have no machine to
> >verify.
>
> Your test case works correctly for me on sparc-linux (both 32-bit and
> 64-bit on ext4 and xfs filesystems):
>
> $ uname -a
> Linux gcc202 5.10.0-4-sparc64-smp #1 SMP Debian 5.10.19-1 (2021-03-02) sparc64 GNU/Linux
> $ apt list libc6
> Listing... Done
> libc6/unstable,now 2.31-4 sparc64 [installed]
> $ ./a.out
> $ TZ= stat test
>    File: test
>    Size: 0               Blocks: 0          IO Block: 8192   regular empty file
> Device: fd01h/64769d    Inode: 657291843   Links: 1
> Access: (0644/-rw-r--r--)  Uid: ( 1049/ jwakely)   Gid: ( 1049/ jwakely)
> Access: 2021-03-08 10:25:43.593819539 +0000
> Modify: 1969-12-31 23:39:59.985000000 +0000
> Change: 2021-03-08 10:34:13.711287778 +0000
>   Birth: 2021-03-08 10:24:27.106598699 +0000
>


-- 
YunQiang Su

  reply	other threads:[~2021-03-08 11:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-08  6:35 Chen Li
2021-03-08  6:41 ` YunQiang Su
2021-03-08 10:57 ` Jonathan Wakely
2021-03-08 11:15   ` YunQiang Su [this message]
2021-03-10  3:31 Chen Li

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='CAKcpw6U8g1GExXC0yHN-3SYgy0GbEYbft72N3=1-yUXBy2WETA@mail.gmail.com' \
    --to=wzssyqa@gmail.com \
    --cc=chenli@uniontech.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jwakely@redhat.com \
    --cc=libstdc++@gcc.gnu.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).