[aarch64-port-dev ] RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port

[Andrew Dinn]

On Tue, 18 Jan 2022 21:32:21 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> Backport of JEP-391 to jdk11u-dev
>> The PR has two commits, one is simple copy of linux_aarch64 to bsd_aarch64. This will allow to see the difference applied to os_cpu against linux_aarch64 version.
>> 
>> Total issues:
>> JDK-8253795: Implementation of JEP 391: macOS/AArch64 Port
>> JDK-8253816: Support macOS W^X
>> JDK-8253817: Support macOS Aarch64 ABI in Interpreter
>> JDK-8253818: Support macOS Aarch64 ABI for compiled wrappers
>> JDK-8253819: Implement os/cpu for macOS/AArch64
>> JDK-8253839: Update tests and JDK code for macOS/Aarch64
>> JDK-8254941: Implement Serviceability Agent for macOS/AArch64
>> JDK-8255776: Change build system for macOS/AArch64
>> JDK-8262903: [macos_aarch64] Thread::current() called on detached thread
>> JDK-8262896: [macos_aarch64] Crash in jni_fast_GetLongField
>
> So what ErrorHandlerTest=12 does is basically this:
>  char * const dataPtr = NULL;
>  *dataPtr = '\0';
> 
> and this code alone ( in a simple app) does behave differently on mac_intel and mac_arm ( both with ulimit -c unlimited and user writable /cores folder)
> 
> mac_intel does this:
> Segmentation fault: 11 (core dumped)
> the core is then present in /cores folder
> 
> mac_arm does this:
> zsh: segmentation fault  ./testcrash
> and printing this in dmesg:
> [542308.736586]: AMFI: Denying core dump for pid 2283 (testcrash)testcrash[2283] Corpse allowed 1 of 5
> 
> so I believe the correct way is the way number 2
> If no objections, I will update the PR in few days to ignore this test on mac_arm

@VladimirKempik I agree the best approach is just to exclude this on macos-aarch64.

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

PR: https://git.openjdk.java.net/aarch64-port/pull/14