Re: RFR: 8278275: Initial nroff manpage generation for JDK 19
On Mon, 13 Dec 2021 05:51:37 GMT, David Holmes wrote: > Trivial update to change the version to 19-ea, and update the single > reference to the "current release". > > Content changes for 19 will follow. > > Thanks, > David Thanks for the reviews Erik, Jon and Iris! - PR: https://git.openjdk.java.net/jdk/pull/6811
Integrated: 8278275: Initial nroff manpage generation for JDK 19
On Mon, 13 Dec 2021 05:51:37 GMT, David Holmes wrote: > Trivial update to change the version to 19-ea, and update the single > reference to the "current release". > > Content changes for 19 will follow. > > Thanks, > David This pull request has now been integrated. Changeset: 624f3094 Author:David Holmes URL: https://git.openjdk.java.net/jdk/commit/624f3094b89976a0be0a1d1d4ce304f4be38fb9e Stats: 29 lines in 28 files changed: 0 ins; 0 del; 29 mod 8278275: Initial nroff manpage generation for JDK 19 Reviewed-by: erikj, jjg, iris - PR: https://git.openjdk.java.net/jdk/pull/6811
Re: RFR: 8278275: Initial nroff manpage generation for JDK 19
On Mon, 13 Dec 2021 05:51:37 GMT, David Holmes wrote: > Trivial update to change the version to 19-ea, and update the single > reference to the "current release". > > Content changes for 19 will follow. > > Thanks, > David Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6811
Re: RFR: 8278275: Initial nroff manpage generation for JDK 19
On Mon, 13 Dec 2021 05:51:37 GMT, David Holmes wrote: > Trivial update to change the version to 19-ea, and update the single > reference to the "current release". > > Content changes for 19 will follow. > > Thanks, > David Marked as reviewed by jjg (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6811
Re: glibc 2.12 support
* erik joelsson: > Hello Florian, > > We still build with glibc 2.12 in the sysroot at Oracle as we still > support Oracle Linux 6 (which uses glibc 2.12), so I'm afraid we still > need it. Fair enough. I will tack another thing to the side of this then. 8-> Thanks, Florian
Re: glibc 2.12 support
Hello Florian, We still build with glibc 2.12 in the sysroot at Oracle as we still support Oracle Linux 6 (which uses glibc 2.12), so I'm afraid we still need it. /Erik On 2021-12-13 05:21, Florian Weimer wrote: It seems that building against glibc 2.12 is still supported. Is this something that is still needed? I'm mostly concerned with this fallback code on x86-64: // Unfortunately we have to bring all these macros here from vsyscall.h // to be able to compile on old linuxes. #define __NR_vgetcpu 2 #define VSYSCALL_START (-10UL << 20) #define VSYSCALL_SIZE 1024 #define VSYSCALL_ADDR(vsyscall_nr) (VSYSCALL_START+VSYSCALL_SIZE*(vsyscall_nr)) typedef long (*vgetcpu_t)(unsigned int *cpu, unsigned int *node, unsigned long *tcache); vgetcpu_t vgetcpu = (vgetcpu_t)VSYSCALL_ADDR(__NR_vgetcpu); retval = vgetcpu(&cpu, NULL, NULL); There is no way to check that the kernel actually supports vsyscall, and on some kernels, this will crash because they have disabled vsyscall. I would like to remove this or switch over to the system call (as already used on i386). This is fallback code only, so performance does not really matter: on newer glibc (starting with 2.14), sched_getcpu will be found, and it will use vDSO or rseq as appropriate. Thanks, Florian
Re: RFR: 8278275: Initial nroff manpage generation for JDK 19
On Mon, 13 Dec 2021 05:51:37 GMT, David Holmes wrote: > Trivial update to change the version to 19-ea, and update the single > reference to the "current release". > > Content changes for 19 will follow. > > Thanks, > David Looks good to me. - Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6811
glibc 2.12 support
It seems that building against glibc 2.12 is still supported. Is this something that is still needed? I'm mostly concerned with this fallback code on x86-64: // Unfortunately we have to bring all these macros here from vsyscall.h // to be able to compile on old linuxes. #define __NR_vgetcpu 2 #define VSYSCALL_START (-10UL << 20) #define VSYSCALL_SIZE 1024 #define VSYSCALL_ADDR(vsyscall_nr) (VSYSCALL_START+VSYSCALL_SIZE*(vsyscall_nr)) typedef long (*vgetcpu_t)(unsigned int *cpu, unsigned int *node, unsigned long *tcache); vgetcpu_t vgetcpu = (vgetcpu_t)VSYSCALL_ADDR(__NR_vgetcpu); retval = vgetcpu(&cpu, NULL, NULL); There is no way to check that the kernel actually supports vsyscall, and on some kernels, this will crash because they have disabled vsyscall. I would like to remove this or switch over to the system call (as already used on i386). This is fallback code only, so performance does not really matter: on newer glibc (starting with 2.14), sched_getcpu will be found, and it will use vDSO or rseq as appropriate. Thanks, Florian
Re: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection for Linux/AArch64 [v10]
On Mon, 13 Dec 2021 09:56:41 GMT, Andrew Haley wrote: >> You can support one without the other. >> The architecture allows you to have one without the other. >> The GCC flag is an enum of "none|standard|pac-ret[+leaf]|bti", with some of >> them changing depending on which cpu you specify to -mcpu (8.0,8.3,8.5 etc). >> Clang has the same flags. Interestingly, on MacOS Clang, -mbranch-protection >> is available but it'll give incorrect code. Instead you build with -arch >> arm64e. >> >> If your system had both, the only scenario I could see for only wanting just >> one would be for test/dev purposes. In a real production scenario you would >> want everything the system supports or nothing. >> >> An earlier version of my code had a >> UseBranchProtection="pac|bti|pac+bti|all|none" style option > >> You can support one without the other. The architecture allows you to have >> one without the other. The GCC flag is an enum of >> "none|standard|pac-ret[+leaf]|bti", with some of them changing depending on >> which cpu you specify to -mcpu (8.0,8.3,8.5 etc). Clang has the same flags. > > OK, so we have a precedent. > >> If your system had both, the only scenario I could see for only wanting just >> one would be for test/dev purposes. In a real production scenario you would >> want everything the system supports or nothing. > > Yes. > >> An earlier version of my code had a >> UseBranchProtection="pac|bti|pac+bti|all|none" style option > > That sounds great. > > It seems to me that following the GCC/Clang precedent is the wisest thing we > could do. I can see no possible advantage in diverging: it only confuses > programmers. That gives us: A new flag -XX:UseBranchProtection With the options: none - no PAC support. (Default) standard - PAC support if the system supports it and the java binary was compiled with PAC. Otherwise off. pac-ret - PAC support, regardless if the system supports it or the java binary was compiled with PAC. A later BTI patch would add: standard - also adds BTI if the system supports it and the java binary was compiled with BTI. bti - BTI support, regardless if the system supports it or the java binary was compiled with BTI. Also, concat the flags with "+". Eg: standard+bti. No need to do this until BTI is added. For MacOS, you can only use PAC functionality when compiled for arm64e. Therefore arm64e would be supported by compiling the java binary for the arm64e and would always be enabled in that scenario. UseBranchProtection on MacoOS will only support the none option. - PR: https://git.openjdk.java.net/jdk/pull/6334
Re: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection for Linux/AArch64 [v10]
On Mon, 13 Dec 2021 09:50:26 GMT, Alan Hayward wrote: > You can support one without the other. The architecture allows you to have > one without the other. The GCC flag is an enum of > "none|standard|pac-ret[+leaf]|bti", with some of them changing depending on > which cpu you specify to -mcpu (8.0,8.3,8.5 etc). Clang has the same flags. OK, so we have a precedent. > If your system had both, the only scenario I could see for only wanting just > one would be for test/dev purposes. In a real production scenario you would > want everything the system supports or nothing. Yes. > An earlier version of my code had a > UseBranchProtection="pac|bti|pac+bti|all|none" style option That sounds great. It seems to me that following the GCC/Clang precedent is the wisest thing we could do. I can see no possible advantage in diverging: it only confuses programmers. - PR: https://git.openjdk.java.net/jdk/pull/6334
Re: RFR: 8277204: Implementation of JEP 8264130: PAC-RET protection for Linux/AArch64 [v10]
On Sun, 12 Dec 2021 10:19:30 GMT, Andrew Haley wrote: >> `-mbranch-protection` switches on both PAC-RET and BTI. This PR only covers >> a use of PAC that looks very ROP-focused to me. > > True, because we don't (yet) support BTI. Is there any point having two > separate flags for BTI and PAC-RET? If someone wants one, they'll very likely > want the other, won't they? You can support one without the other. The architecture allows you to have one without the other. The GCC flag is an enum of "none|standard|pac-ret[+leaf]|bti", with some of them changing depending on which cpu you specify to -mcpu (8.0,8.3,8.5 etc). Clang has the same flags. Interestingly, on MacOS Clang, -mbranch-protection is available but it'll give incorrect code. Instead you build with -arch arm64e. If your system had both, the only scenario I could see for only wanting just one would be for test/dev purposes. In a real production scenario you would want everything the system supports or nothing. An earlier version of my code had a UseBranchProtection="pac|bti|pac+bti|all|none" style option - PR: https://git.openjdk.java.net/jdk/pull/6334
