linux-user - time64 question

linux-user - time64 question

[Sid Manning]

[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]

I’m looking at a testcase failure when my target uses 64bit time in msg.h (struct msqid_ds).  I’ve been able to get around this but changing target_msqid_ds like so:

@@ -3900,18 +3901,9 @@ static inline abi_long do_semop(int semid, abi_long ptr,
unsigned nsops)
 struct target_msqid_ds
 {
     struct target_ipc_perm msg_perm;
-    abi_ulong msg_stime;
-#if TARGET_ABI_BITS == 32
-    abi_ulong __unused1;
-#endif
-    abi_ulong msg_rtime;
-#if TARGET_ABI_BITS == 32
-    abi_ulong __unused2;
-#endif
-    abi_ulong msg_ctime;
-#if TARGET_ABI_BITS == 32
-    abi_ulong __unused3;
-#endif
+    abi_ullong msg_stime;
+    abi_ullong msg_rtime;
+    abi_ullong msg_ctime;
     abi_ulong __msg_cbytes;
     abi_ulong msg_qnum;
     abi_ulong msg_qbytes;

It seems like either should have worked but I get garbage back in some of the elements below msg_time fields without the change.

If time_t is 64bits then it seems like stime/rtime/ctime should be abi_ullong.

My target is Hexagon and the TARGET_ABI_BITS is 32.

Thanks,

[-- Attachment #2: Type: text/html, Size: 2517 bytes --]

Re: linux-user - time64 question

[Laurent Vivier]

Le 05/05/2020 à 23:38, Sid Manning a écrit :
> I’m looking at a testcase failure when my target uses 64bit time in
> msg.h (struct msqid_ds).  I’ve been able to get around this but changing
> target_msqid_ds like so:
> 
> 
> @@ -3900,18 +3901,9 @@ static inline abi_long do_semop(int semid,
> abi_long ptr,
> unsigned nsops)
>  struct target_msqid_ds
>  {
>      struct target_ipc_perm msg_perm;
> -    abi_ulong msg_stime;
> -#if TARGET_ABI_BITS == 32
> -    abi_ulong __unused1;
> -#endif
> -    abi_ulong msg_rtime;
> -#if TARGET_ABI_BITS == 32
> -    abi_ulong __unused2;
> -#endif
> -    abi_ulong msg_ctime;
> -#if TARGET_ABI_BITS == 32
> -    abi_ulong __unused3;
> -#endif
> +    abi_ullong msg_stime;
> +    abi_ullong msg_rtime;
> +    abi_ullong msg_ctime;
>      abi_ulong __msg_cbytes;
>      abi_ulong msg_qnum;
>      abi_ulong msg_qbytes;
> 
> It seems like either should have worked but I get garbage back in some
> of the elements below msg_time fields without the change.
> 
> If time_t is 64bits then it seems like stime/rtime/ctime should be
> abi_ullong.
> 
> My target is Hexagon and the TARGET_ABI_BITS is 32.

The structure has been changed into the kernel for the y2038 and the
change has not been reflected into qemu (and it needs).

See kernel commit:

c2ab975c30f0 ("y2038: ipc: Report long times to user space")

Thanks,
Laurent

RE: linux-user - time64 question

[Sid Manning]

> -----Original Message-----
> From: Laurent Vivier <laurent@vivier.eu>
> Sent: Wednesday, May 27, 2020 11:23 AM
> To: Sid Manning <sidneym@quicinc.com>; qemu-devel@nongnu.org
> Subject: [EXT] Re: linux-user - time64 question
>
> Le 05/05/2020 à 23:38, Sid Manning a écrit :
> > I’m looking at a testcase failure when my target uses 64bit time in
> > msg.h (struct msqid_ds).  I’ve been able to get around this but
> > changing target_msqid_ds like so:
> >
> >
> > @@ -3900,18 +3901,9 @@ static inline abi_long do_semop(int semid,
> > abi_long ptr, unsigned nsops)
> >  struct target_msqid_ds
> >  {
> >      struct target_ipc_perm msg_perm;
> > -    abi_ulong msg_stime;
> > -#if TARGET_ABI_BITS == 32
> > -    abi_ulong __unused1;
> > -#endif
> > -    abi_ulong msg_rtime;
> > -#if TARGET_ABI_BITS == 32
> > -    abi_ulong __unused2;
> > -#endif
> > -    abi_ulong msg_ctime;
> > -#if TARGET_ABI_BITS == 32
> > -    abi_ulong __unused3;
> > -#endif
> > +    abi_ullong msg_stime;
> > +    abi_ullong msg_rtime;
> > +    abi_ullong msg_ctime;
> >      abi_ulong __msg_cbytes;
> >      abi_ulong msg_qnum;
> >      abi_ulong msg_qbytes;
> >
> > It seems like either should have worked but I get garbage back in some
> > of the elements below msg_time fields without the change.
> >
> > If time_t is 64bits then it seems like stime/rtime/ctime should be
> > abi_ullong.
> >
> > My target is Hexagon and the TARGET_ABI_BITS is 32.
>
> The structure has been changed into the kernel for the y2038 and the change
> has not been reflected into qemu (and it needs).

Thanks for the info.  It was also pointed out to me that my C-library was missing  a #define, #define IPC_STAT 0x102
This caused the library not to recognize 64-bit time in some instances.


>
> See kernel commit:
>
> c2ab975c30f0 ("y2038: ipc: Report long times to user space")
>
> Thanks,
> Laurent