On Mon, 13 Dec 2021 11:48:52 GMT, Alan Hayward <d...@openjdk.java.net> 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. > > 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. Updated to the above. The CSR will need an update too. ------------- PR: https://git.openjdk.java.net/jdk/pull/6334
