RFR: 8318696: Do not use LFS64 symbols on Linux

[Sam James]

On Fri, 15 Dec 2023 12:28:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

>From what version of glibc can we be sure that the non-64 version is exactly equivalent to the 64 version for all these functions?

Fortunately, support for `_FILE_OFFSET_BITS=64` making `off_t` 64-bit has been supported for quite a long time in glibc (unlike 64-bit `time_t` on 32-bit arches which is _way_ more recent, like the last 2 years...).

It dates back to 1997. The exception is for `fts.h` which got wired up in 2015 (8b7b7f75d91f7bac323dd6a370aeb3e9c5c4a7d5) (glibc-2.23). OpenJDK doesn't use fts, so we're fine. It errored out before then anyway, it didn't silently fallback to 32-bit.

>There are also uses of some 64 functions in the JDK code as well.

This requires closer inspection to determine how broken they are outside of these changes.

For some of the cases in the JDK code, `foo64()` functions are only used in some cases on AIX, leaving `foo()` used on e.g. 32-bit Linux. Some of them might be semantically broken already, not just at build-time with newer musl where `off_t` is always 64-bit.

My preference for moving forward is:
1) I add some `static_assert` for `off_t` to the modified JVM bits to be safe (that's what I tested with);
2) We keep this PR for the build-only fixes which are semantically identical to the previous code - this PR currently "preserves" bitness, it doesn't fix anything other than avoiding use of `foo64()` where it's unnecessary by converting to foo, but the `foo64()` use was right - just a glibcism - until now. From what I can tell, the JVM code touched here was correct, just relying on glibcisms;
3) In another PR, we look at the general 32-bit LFS situation which may involve runtime fixes if - as it appears - `off_t` is actually 32-bit on x86 systems right now and non `foo64()` functions are being used. Then we either port more stuff to use `foo64()` (not ideal), or consistently use `foo()` in more places with `FILE_OFFSET_BITS`.

My hope is to separate these semantic changes from the equivalent-behaviour stuff both to ease review but also because there's a bunch of projects which need noop fixes like this still that I need to look at.

I can't promise to be able to do 3) immediately though. I can probably start it soon, I just can't promise to get the whole thing done quickly.

What do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/16329#issuecomment-1858739783