Make HgfsConvertFromNtTimeNsec aware of 64-bit time_t on i386

[beevvy]

I verified that this function behaves as expected on x86_64, i386 with
32-bit time_t, and i386 with 64-bit time_t for the following values of
ntTtime:

UNIX_EPOCH-1, UNIX_EPOCH, UNIX_EPOCH+1, UNIX_S32_MAX-1, UNIX_S32_MAX,
UNIX_S32_MAX+1, UNIX_S32_MAX*2+1

I did not verify whether the use of Div643264 is optimal, performance
wise.

[vmwclabot]

@beevvy, you must sign our contributor license agreement before your changes are merged. Click here to sign the agreement. If you are a VMware employee, read this for further instruction.

[beevvy]

Hm, a couple notes upon further inquiry:

1. lib/misc/timeutil.c needs an analogous update. Probably a couple other spots, too.
2. Div643264 generates incorrect code for me with gcc 9.2.0, as it misses the earlyclobber flag for the eax and edx registers. This is bad. If you folks use this anywhere else, this should really be fixed (or removed completely). For me it generated code that misbehaved only for y>2106 dates, but ymmv.
3. That said, it's doubtful if this i386-specific code accomplishes any measurable improvement nowadays. Consider removing it completely and just using generic code.

I can update the pull request addressing all of these if you folks indicate the desired course of action for (2) and (3).

[vmwclabot]

@beevvy, VMware has approved your signed contributor license agreement.

[rwmacleod]

Was this forgotten? I don't see it in the git log.

[lousybrit]

Was this forgotten? I don't see it in the git log.

Not intentionally dropped. The resources for updating this feature have not been monitoring this.
Thank you for the reminder!

[VinodKumarGoku]

Thanks for your contribution. Your contribution will go through a review process at VMware. An update will be provided once the review is completed.

I have started to work on PR. It would be great if you could please share your test setup or steps you performed to test the fix.

[beevvy]

Hi @VinodKumarGoku, I'm sorry, but I've since lost interest in this patch. Fur sure, this was developed against an i386 environment based on musl libc. This of course also applies to i386 glibc systems with 64-bit time_t, but I don't know what is the state of glibc nowadays in this regard.

Perhaps @kraj or @giuliobenetti could help you here, I believe they applied this patch in Yocto and Buildroot, respectively. Please do keep in mind my comments from #387 (comment) - they are probably still relevant.

[giuliobenetti]

Hi @beevvy and @VinodKumarGoku,

this patch is still used in Buildroot and to reproduce the bug and check it is solved with this patch you can:

$ git clone git://git.busybox.net/buildroot
$ cd buildroot
$ git checkout eb3dfe679536b578a0f16762312a96ada7162095
$ wget -O .config http://autobuild.buildroot.net/results/eb3dfe679536b578a0f16762312a96ada7162095/config
$ make olddefconfig && make

After the builds fail you can pick this pending patch and copy and paste it to buildroot/package/openvmtools/0012-The-pending-patch.patch

And then rebuild the single package with:

make openvmtools-dirclean openvmtools

That way the build failure should disappear.

[kraj]

We support musl in Yocto/OpenEmbedded which has moved to using 64bit time_t on 32bit hosts. You can perhaps also reproduce the problem with riscv32 and glibc.