RFR: JDK-8298448: UndefinedBehaviorSanitizer [v9]

[Justin King]

On Sat, 17 Dec 2022 06:33:43 GMT, Justin King <jcking at openjdk.org> wrote:

>> Allow building OpenJDK with UBSan. Currently the build fails when optimizing the image due to lots of undefined behavior (it invokes the built JVM). Follow up PRs will either replace the undefined behavior with well defined behavior or suppress errors which are intentional. The goal is to make OpenJDK more well defined and thus more portable across compilers and architectures.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update approach based on feedback from @magicus
>   
>   Signed-off-by: Justin King <jcking at google.com>

> I much also check: is this really needed for _all_ executables we make? I would have guessed that it would suffice with the "launchers", i.e. like `java`, `javac`, `jar` etc. These are all compiled from a single source file, `src/java.base/share/native/launcher/main.c`, with different defines depending on what Java classes it should actually launch, and with different output names.
> 
> Doing things this way will also affect non-launcher executables, like `jabswitch`, `msiwrapper` and all executable test binaries.
> 
> That might be correct, but I could not be certain of that from trying to read the backlog of discussion in this bug.

For UBSan, the inclusion in every executable is intentional. For upcoming LSan/ASan stuff, it will be just for launchers. The reason is that UBSan is relaxed by default and won't terminate upon undefined behavior. LSan/ASan are strict by default, and for LSan to work we need to disable some things only when the JVM is being used. So for this commit all executables is correct. For ASan/LSan as you suggest only launchers will have them in that case.

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

PR: https://git.openjdk.org/jdk/pull/11604