RFR: 8336529: (fs) UnixFileAttributeViews setTimes() failing on armhf, Ubuntu noble [v2]

[Jaikiran Pai]

On Thu, 18 Jul 2024 07:18:48 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> [1] https://wiki.debian.org/ReleaseGoals/64bit-time

Thank you for that link. Reading through it, it leads to https://sourceware.org/glibc/wiki/Y2038ProofnessDesign. The summary of that, if I understood correctly, is that the `time_t` related functions and types for 32 bit systems will have 64 bit equivalents (with newer type names and API names). The 64 bit variants will get used when built with `_TIME_BITS=64`. The glibc project appears to try and keep this as seamless as possible, to user code, by internally `#define`ing 32 bit API and type names to their corresponding 64 bit names, when `_TIME_BITS=64` is set.

Looking at the JBS issue where you reported these test failures, they seem to be happening on `armhf` architecture, which after reading up a bit, appears to be a 32 bit architecture. Ubuntu recently appears to have switched to use `_TIME_BITS=64` for this architecture. This, if I understand correctly, wouldn't have been a problem for the JDK code, had those symbols be referenced statically in the JDK code, since then the (glibc) `#define` would have translated it to the 64 bit counterpart. In the code which is being updated in this PR, we reference those symbols as strings to do a dynamic symbol lookup and that ends up giving back 32 bit variant of this API.

Did I understand this correctly?

The one unanswered question is - on this 32 bit system, how were these tests passing previously, when `_TIME_BITS=64` wasn't set. Perhaps, in the absence of the `_TIME_BITS=64`, the symbols were being mapped to 64 bit counterparts? Would you be able to verify that somehow on a `armhf` system where these tests pass?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20208#issuecomment-2236362756