On Sat, 4 Nov 2023 06:39:34 GMT, Thomas Stuefe <stu...@openjdk.org> wrote:
>> See [JDK-8288719](https://bugs.openjdk.org/browse/JDK-8288719) and >> subsequent >> [discussion](https://mail.openjdk.org/pipermail/build-dev/2022-May/034635.html) >> back in 2022. >> >> On Arm, we can generate either arm- or thumb-code (`-marm` or `-mthumb`). >> >> At the moment, if we don't specify an ABI profile (`--with_abi_profile`) >> when configuring the build, we call gcc without `-marm` or `-mthumb`. Then >> we use whatever the toolchain defaults too, which is pretty much random (it >> depends on how the toolchain itself had been built). That can cause really >> rare but tricky problems when combining static assembly and C++ code (See >> e.g. JDK-8288719). >> >> I propose to always specify `-marm` as default, unless an ABI profile is >> given, to prevent such errors. >> >> Thanks to @marchof for testing this. > > Thomas Stuefe has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains eight additional > commits since the last revision: > > - Merge branch 'openjdk:master' into > JDK-8313790-arm32-Specify-marm-when-building-without-an-ABI-profile > - Merge branch 'openjdk:master' into > JDK-8313790-arm32-Specify-marm-when-building-without-an-ABI-profile > - Merge branch 'openjdk:master' into > JDK-8313790-arm32-Specify-marm-when-building-without-an-ABI-profile > - Merge branch 'openjdk:master' into > JDK-8313790-arm32-Specify-marm-when-building-without-an-ABI-profile > - Merge branch 'openjdk:master' into > JDK-8313790-arm32-Specify-marm-when-building-without-an-ABI-profile > - Merge branch 'openjdk:master' into > JDK-8313790-arm32-Specify-marm-when-building-without-an-ABI-profile > - Merge branch 'openjdk:master' into > JDK-8313790-arm32-Specify-marm-when-building-without-an-ABI-profile > - start I thought `--with-abi-profile` was required when building on arm32. Would that not be a better fix to do? (And even if we don't go that route, I think it would be better to have an "else" clause that sets the fallback value you propose here, rather than to set it once at the start and then overwrite it for almost all cases.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/15162#issuecomment-1794703170 PR Comment: https://git.openjdk.org/jdk/pull/15162#issuecomment-1794705921
