[android] Enable ARM_SOFTFP for Android ARM32 to fix SIGSEGV in DateTime.Now

[Copilot]

Android armeabi-v7a mandates the softfp calling convention (-mfloat-abi=softfp): float args pass through integer registers at call boundaries even though VFP is used for arithmetic. After #127225 enabled RyuJIT for android-arm, the JIT was never told to use softfp, so it treated the ABI as hardfp. Math.Truncate calls ModF(d, &d) — but with no stack slot allocated for d (it lives in d0), &d is null → SIGSEGV before any test runs.

Description

• eng/native/configureplatform.cmake: Set ARM_SOFTFP=1 when CLR_CMAKE_TARGET_ARCH=arm and CLR_CMAKE_TARGET_OS=android. This feeds into the existing configurecompiler.cmake path that globally emits -DARM_SOFTFP and -mfloat-abi=softfp, aligning the JIT's codegen ABI assumptions with the NDK default.

• src/coreclr/clrdefinitions.cmake: Extend the ARM_SOFTFPtarget_compile_definitions in set_target_definitions_to_custom_os_and_arch to also cover arch=arm when CLR_CMAKE_TARGET_ANDROID is set. This ensures JIT/gcinfo cross-compilation targets get the correct define.

# Before: only armel (soft-float embedded Linux) got ARM_SOFTFPif (TARGETDETAILS_ARCH STREQUAL"armel")
# After: Android ARM32 also needs softfpif (TARGETDETAILS_ARCH STREQUAL"armel"OR
(TARGETDETAILS_ARCH STREQUAL"arm"AND CLR_CMAKE_TARGET_ANDROID))

Customer Impact

Hard crash (SIGSEGV) on startup of any .NET app running on Android ARM32 with the CoreCLR runtime. Affects every test leg on android-arm, blocking all PRs that trigger those legs.

Regression

Yes — introduced by #127225 (merged 2026-04-28) which first enabled the CoreCLR JIT on android-arm. No prior release shipped android-arm CoreCLR support, so no stable release is affected.

Testing

The fix is build-system / compile-flag only. Correctness is validated by the android-arm CI leg added in #127225 — the SIGSEGV crash on DateTime.get_Now() during test runner init will no longer occur once the JIT correctly spills float parameters to stack slots.

Risk

Low. The change mirrors exactly what is already done for armel (soft-float embedded Linux). It only activates when CLR_CMAKE_TARGET_OS=android + CLR_CMAKE_TARGET_ARCH=arm, leaving all other targets unaffected.

Package authoring no longer needed in .NET 9

IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older versions.

[jakobbotsch]

Let's see how this works out... I don't think we ever tested the softfp support in our own CI, and this support was added many years ago by Samsung, so it may be quite bitrotted at this point.
I do think they have been using the armel support since then, so it may not be too bad.

[mangod9]

It appears the DateTime issue is resolved but there are other failures with that leg. Dont think android-arm on coreclr is ready to be in CI yet. The change should be reverted till the leg is validated for longer @simonrozsival ?

[simonrozsival]

Dont think android-arm on coreclr is ready to be in CI yet.

@mangod9 I agree. #127225 was merged without adequate validation. Reverting in #127547.

[mangod9]

Closing this since the android-arm PR is reverted. This change might be needed before enabling again, but appears it needs other investigations to enable.

[Copilot]

Android armeabi-v7a mandates the softfp calling convention (-mfloat-abi=softfp): float args pass through integer registers at call boundaries even though VFP is used for arithmetic. After #127225 enabled RyuJIT for android-arm, the JIT was never told to use softfp, so it treated the ABI as hardfp. Math.Truncate calls ModF(d, &d) — but with no stack slot allocated for d (it lives in d0), &d is null → SIGSEGV before any test runs.

Description

• eng/native/configureplatform.cmake: Set ARM_SOFTFP=1 when CLR_CMAKE_TARGET_ARCH=arm and CLR_CMAKE_TARGET_OS=android. This feeds into the existing configurecompiler.cmake path that globally emits -DARM_SOFTFP and -mfloat-abi=softfp, aligning the JIT's codegen ABI assumptions with the NDK default.

• src/coreclr/clrdefinitions.cmake: Extend the ARM_SOFTFPtarget_compile_definitions in set_target_definitions_to_custom_os_and_arch to also cover arch=arm when CLR_CMAKE_TARGET_ANDROID is set. This ensures JIT/gcinfo cross-compilation targets get the correct define.

# Before: only armel (soft-float embedded Linux) got ARM_SOFTFPif (TARGETDETAILS_ARCH STREQUAL"armel")
# After: Android ARM32 also needs softfpif (TARGETDETAILS_ARCH STREQUAL"armel"OR
(TARGETDETAILS_ARCH STREQUAL"arm"AND CLR_CMAKE_TARGET_ANDROID))

Customer Impact

Hard crash (SIGSEGV) on startup of any .NET app running on Android ARM32 with the CoreCLR runtime. Affects every test leg on android-arm, blocking all PRs that trigger those legs.

Regression

Yes — introduced by #127225 (merged 2026-04-28) which first enabled the CoreCLR JIT on android-arm. No prior release shipped android-arm CoreCLR support, so no stable release is affected.

Testing

The fix is build-system / compile-flag only. Correctness is validated by the android-arm CI leg added in #127225 — the SIGSEGV crash on DateTime.get_Now() during test runner init will no longer occur once the JIT correctly spills float parameters to stack slots.

Risk

Low. The change mirrors exactly what is already done for armel (soft-float embedded Linux). It only activates when CLR_CMAKE_TARGET_OS=android + CLR_CMAKE_TARGET_ARCH=arm, leaving all other targets unaffected.

Package authoring no longer needed in .NET 9

IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older versions.

[jakobbotsch]

Let's see how this works out... I don't think we ever tested the softfp support in our own CI, and this support was added many years ago by Samsung, so it may be quite bitrotted at this point.
I do think they have been using the armel support since then, so it may not be too bad.

[mangod9]

It appears the DateTime issue is resolved but there are other failures with that leg. Dont think android-arm on coreclr is ready to be in CI yet. The change should be reverted till the leg is validated for longer @simonrozsival ?

[simonrozsival]

Dont think android-arm on coreclr is ready to be in CI yet.

@mangod9 I agree. #127225 was merged without adequate validation. Reverting in #127547.

[mangod9]

Closing this since the android-arm PR is reverted. This change might be needed before enabling again, but appears it needs other investigations to enable.

[Copilot]

Android armeabi-v7a mandates the softfp calling convention (-mfloat-abi=softfp): float args pass through integer registers at call boundaries even though VFP is used for arithmetic. After #127225 enabled RyuJIT for android-arm, the JIT was never told to use softfp, so it treated the ABI as hardfp. Math.Truncate calls ModF(d, &d) — but with no stack slot allocated for d (it lives in d0), &d is null → SIGSEGV before any test runs.

Description

• eng/native/configureplatform.cmake: Set ARM_SOFTFP=1 when CLR_CMAKE_TARGET_ARCH=arm and CLR_CMAKE_TARGET_OS=android. This feeds into the existing configurecompiler.cmake path that globally emits -DARM_SOFTFP and -mfloat-abi=softfp, aligning the JIT's codegen ABI assumptions with the NDK default.

• src/coreclr/clrdefinitions.cmake: Extend the ARM_SOFTFPtarget_compile_definitions in set_target_definitions_to_custom_os_and_arch to also cover arch=arm when CLR_CMAKE_TARGET_ANDROID is set. This ensures JIT/gcinfo cross-compilation targets get the correct define.

# Before: only armel (soft-float embedded Linux) got ARM_SOFTFPif (TARGETDETAILS_ARCH STREQUAL"armel")
# After: Android ARM32 also needs softfpif (TARGETDETAILS_ARCH STREQUAL"armel"OR
(TARGETDETAILS_ARCH STREQUAL"arm"AND CLR_CMAKE_TARGET_ANDROID))

Customer Impact

Hard crash (SIGSEGV) on startup of any .NET app running on Android ARM32 with the CoreCLR runtime. Affects every test leg on android-arm, blocking all PRs that trigger those legs.

Regression

Yes — introduced by #127225 (merged 2026-04-28) which first enabled the CoreCLR JIT on android-arm. No prior release shipped android-arm CoreCLR support, so no stable release is affected.

Testing

The fix is build-system / compile-flag only. Correctness is validated by the android-arm CI leg added in #127225 — the SIGSEGV crash on DateTime.get_Now() during test runner init will no longer occur once the JIT correctly spills float parameters to stack slots.

Risk

Low. The change mirrors exactly what is already done for armel (soft-float embedded Linux). It only activates when CLR_CMAKE_TARGET_OS=android + CLR_CMAKE_TARGET_ARCH=arm, leaving all other targets unaffected.

Package authoring no longer needed in .NET 9

IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older versions.

[jakobbotsch]

Let's see how this works out... I don't think we ever tested the softfp support in our own CI, and this support was added many years ago by Samsung, so it may be quite bitrotted at this point.
I do think they have been using the armel support since then, so it may not be too bad.

[mangod9]

It appears the DateTime issue is resolved but there are other failures with that leg. Dont think android-arm on coreclr is ready to be in CI yet. The change should be reverted till the leg is validated for longer @simonrozsival ?

[simonrozsival]

Dont think android-arm on coreclr is ready to be in CI yet.

@mangod9 I agree. #127225 was merged without adequate validation. Reverting in #127547.

[mangod9]

Closing this since the android-arm PR is reverted. This change might be needed before enabling again, but appears it needs other investigations to enable.

[Copilot]

Android armeabi-v7a mandates the softfp calling convention (-mfloat-abi=softfp): float args pass through integer registers at call boundaries even though VFP is used for arithmetic. After #127225 enabled RyuJIT for android-arm, the JIT was never told to use softfp, so it treated the ABI as hardfp. Math.Truncate calls ModF(d, &d) — but with no stack slot allocated for d (it lives in d0), &d is null → SIGSEGV before any test runs.

Description

• eng/native/configureplatform.cmake: Set ARM_SOFTFP=1 when CLR_CMAKE_TARGET_ARCH=arm and CLR_CMAKE_TARGET_OS=android. This feeds into the existing configurecompiler.cmake path that globally emits -DARM_SOFTFP and -mfloat-abi=softfp, aligning the JIT's codegen ABI assumptions with the NDK default.

• src/coreclr/clrdefinitions.cmake: Extend the ARM_SOFTFPtarget_compile_definitions in set_target_definitions_to_custom_os_and_arch to also cover arch=arm when CLR_CMAKE_TARGET_ANDROID is set. This ensures JIT/gcinfo cross-compilation targets get the correct define.

# Before: only armel (soft-float embedded Linux) got ARM_SOFTFPif (TARGETDETAILS_ARCH STREQUAL"armel")
# After: Android ARM32 also needs softfpif (TARGETDETAILS_ARCH STREQUAL"armel"OR
(TARGETDETAILS_ARCH STREQUAL"arm"AND CLR_CMAKE_TARGET_ANDROID))

Customer Impact

Hard crash (SIGSEGV) on startup of any .NET app running on Android ARM32 with the CoreCLR runtime. Affects every test leg on android-arm, blocking all PRs that trigger those legs.

Regression

Yes — introduced by #127225 (merged 2026-04-28) which first enabled the CoreCLR JIT on android-arm. No prior release shipped android-arm CoreCLR support, so no stable release is affected.

Testing

The fix is build-system / compile-flag only. Correctness is validated by the android-arm CI leg added in #127225 — the SIGSEGV crash on DateTime.get_Now() during test runner init will no longer occur once the JIT correctly spills float parameters to stack slots.

Risk

Low. The change mirrors exactly what is already done for armel (soft-float embedded Linux). It only activates when CLR_CMAKE_TARGET_OS=android + CLR_CMAKE_TARGET_ARCH=arm, leaving all other targets unaffected.

Package authoring no longer needed in .NET 9

IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older versions.

[jakobbotsch]

Let's see how this works out... I don't think we ever tested the softfp support in our own CI, and this support was added many years ago by Samsung, so it may be quite bitrotted at this point.
I do think they have been using the armel support since then, so it may not be too bad.

[mangod9]

It appears the DateTime issue is resolved but there are other failures with that leg. Dont think android-arm on coreclr is ready to be in CI yet. The change should be reverted till the leg is validated for longer @simonrozsival ?

[simonrozsival]

Dont think android-arm on coreclr is ready to be in CI yet.

@mangod9 I agree. #127225 was merged without adequate validation. Reverting in #127547.

[mangod9]

Closing this since the android-arm PR is reverted. This change might be needed before enabling again, but appears it needs other investigations to enable.

[Copilot]

Android armeabi-v7a mandates the softfp calling convention (-mfloat-abi=softfp): float args pass through integer registers at call boundaries even though VFP is used for arithmetic. After #127225 enabled RyuJIT for android-arm, the JIT was never told to use softfp, so it treated the ABI as hardfp. Math.Truncate calls ModF(d, &d) — but with no stack slot allocated for d (it lives in d0), &d is null → SIGSEGV before any test runs.

Description

• eng/native/configureplatform.cmake: Set ARM_SOFTFP=1 when CLR_CMAKE_TARGET_ARCH=arm and CLR_CMAKE_TARGET_OS=android. This feeds into the existing configurecompiler.cmake path that globally emits -DARM_SOFTFP and -mfloat-abi=softfp, aligning the JIT's codegen ABI assumptions with the NDK default.

• src/coreclr/clrdefinitions.cmake: Extend the ARM_SOFTFPtarget_compile_definitions in set_target_definitions_to_custom_os_and_arch to also cover arch=arm when CLR_CMAKE_TARGET_ANDROID is set. This ensures JIT/gcinfo cross-compilation targets get the correct define.

# Before: only armel (soft-float embedded Linux) got ARM_SOFTFPif (TARGETDETAILS_ARCH STREQUAL"armel")
# After: Android ARM32 also needs softfpif (TARGETDETAILS_ARCH STREQUAL"armel"OR
(TARGETDETAILS_ARCH STREQUAL"arm"AND CLR_CMAKE_TARGET_ANDROID))

Customer Impact

Hard crash (SIGSEGV) on startup of any .NET app running on Android ARM32 with the CoreCLR runtime. Affects every test leg on android-arm, blocking all PRs that trigger those legs.

Regression

Yes — introduced by #127225 (merged 2026-04-28) which first enabled the CoreCLR JIT on android-arm. No prior release shipped android-arm CoreCLR support, so no stable release is affected.

Testing

The fix is build-system / compile-flag only. Correctness is validated by the android-arm CI leg added in #127225 — the SIGSEGV crash on DateTime.get_Now() during test runner init will no longer occur once the JIT correctly spills float parameters to stack slots.

Risk

Low. The change mirrors exactly what is already done for armel (soft-float embedded Linux). It only activates when CLR_CMAKE_TARGET_OS=android + CLR_CMAKE_TARGET_ARCH=arm, leaving all other targets unaffected.

Package authoring no longer needed in .NET 9

IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older versions.

[jakobbotsch]

Let's see how this works out... I don't think we ever tested the softfp support in our own CI, and this support was added many years ago by Samsung, so it may be quite bitrotted at this point.
I do think they have been using the armel support since then, so it may not be too bad.

[mangod9]

It appears the DateTime issue is resolved but there are other failures with that leg. Dont think android-arm on coreclr is ready to be in CI yet. The change should be reverted till the leg is validated for longer @simonrozsival ?

[simonrozsival]

Dont think android-arm on coreclr is ready to be in CI yet.

@mangod9 I agree. #127225 was merged without adequate validation. Reverting in #127547.

[mangod9]

Closing this since the android-arm PR is reverted. This change might be needed before enabling again, but appears it needs other investigations to enable.

[Copilot]

Android armeabi-v7a mandates the softfp calling convention (-mfloat-abi=softfp): float args pass through integer registers at call boundaries even though VFP is used for arithmetic. After #127225 enabled RyuJIT for android-arm, the JIT was never told to use softfp, so it treated the ABI as hardfp. Math.Truncate calls ModF(d, &d) — but with no stack slot allocated for d (it lives in d0), &d is null → SIGSEGV before any test runs.

Description

• eng/native/configureplatform.cmake: Set ARM_SOFTFP=1 when CLR_CMAKE_TARGET_ARCH=arm and CLR_CMAKE_TARGET_OS=android. This feeds into the existing configurecompiler.cmake path that globally emits -DARM_SOFTFP and -mfloat-abi=softfp, aligning the JIT's codegen ABI assumptions with the NDK default.

• src/coreclr/clrdefinitions.cmake: Extend the ARM_SOFTFPtarget_compile_definitions in set_target_definitions_to_custom_os_and_arch to also cover arch=arm when CLR_CMAKE_TARGET_ANDROID is set. This ensures JIT/gcinfo cross-compilation targets get the correct define.

# Before: only armel (soft-float embedded Linux) got ARM_SOFTFPif (TARGETDETAILS_ARCH STREQUAL"armel")
# After: Android ARM32 also needs softfpif (TARGETDETAILS_ARCH STREQUAL"armel"OR
(TARGETDETAILS_ARCH STREQUAL"arm"AND CLR_CMAKE_TARGET_ANDROID))

Customer Impact

Hard crash (SIGSEGV) on startup of any .NET app running on Android ARM32 with the CoreCLR runtime. Affects every test leg on android-arm, blocking all PRs that trigger those legs.

Regression

Yes — introduced by #127225 (merged 2026-04-28) which first enabled the CoreCLR JIT on android-arm. No prior release shipped android-arm CoreCLR support, so no stable release is affected.

Testing

The fix is build-system / compile-flag only. Correctness is validated by the android-arm CI leg added in #127225 — the SIGSEGV crash on DateTime.get_Now() during test runner init will no longer occur once the JIT correctly spills float parameters to stack slots.

Risk

Low. The change mirrors exactly what is already done for armel (soft-float embedded Linux). It only activates when CLR_CMAKE_TARGET_OS=android + CLR_CMAKE_TARGET_ARCH=arm, leaving all other targets unaffected.

Package authoring no longer needed in .NET 9

IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older versions.

[jakobbotsch]

Let's see how this works out... I don't think we ever tested the softfp support in our own CI, and this support was added many years ago by Samsung, so it may be quite bitrotted at this point.
I do think they have been using the armel support since then, so it may not be too bad.

[mangod9]

It appears the DateTime issue is resolved but there are other failures with that leg. Dont think android-arm on coreclr is ready to be in CI yet. The change should be reverted till the leg is validated for longer @simonrozsival ?

[simonrozsival]

Dont think android-arm on coreclr is ready to be in CI yet.

@mangod9 I agree. #127225 was merged without adequate validation. Reverting in #127547.

[mangod9]

Closing this since the android-arm PR is reverted. This change might be needed before enabling again, but appears it needs other investigations to enable.

[Copilot]

Android armeabi-v7a mandates the softfp calling convention (-mfloat-abi=softfp): float args pass through integer registers at call boundaries even though VFP is used for arithmetic. After #127225 enabled RyuJIT for android-arm, the JIT was never told to use softfp, so it treated the ABI as hardfp. Math.Truncate calls ModF(d, &d) — but with no stack slot allocated for d (it lives in d0), &d is null → SIGSEGV before any test runs.

Description

• eng/native/configureplatform.cmake: Set ARM_SOFTFP=1 when CLR_CMAKE_TARGET_ARCH=arm and CLR_CMAKE_TARGET_OS=android. This feeds into the existing configurecompiler.cmake path that globally emits -DARM_SOFTFP and -mfloat-abi=softfp, aligning the JIT's codegen ABI assumptions with the NDK default.

• src/coreclr/clrdefinitions.cmake: Extend the ARM_SOFTFPtarget_compile_definitions in set_target_definitions_to_custom_os_and_arch to also cover arch=arm when CLR_CMAKE_TARGET_ANDROID is set. This ensures JIT/gcinfo cross-compilation targets get the correct define.

# Before: only armel (soft-float embedded Linux) got ARM_SOFTFPif (TARGETDETAILS_ARCH STREQUAL"armel")
# After: Android ARM32 also needs softfpif (TARGETDETAILS_ARCH STREQUAL"armel"OR
(TARGETDETAILS_ARCH STREQUAL"arm"AND CLR_CMAKE_TARGET_ANDROID))

Customer Impact

Hard crash (SIGSEGV) on startup of any .NET app running on Android ARM32 with the CoreCLR runtime. Affects every test leg on android-arm, blocking all PRs that trigger those legs.

Regression

Yes — introduced by #127225 (merged 2026-04-28) which first enabled the CoreCLR JIT on android-arm. No prior release shipped android-arm CoreCLR support, so no stable release is affected.

Testing

The fix is build-system / compile-flag only. Correctness is validated by the android-arm CI leg added in #127225 — the SIGSEGV crash on DateTime.get_Now() during test runner init will no longer occur once the JIT correctly spills float parameters to stack slots.

Risk

Low. The change mirrors exactly what is already done for armel (soft-float embedded Linux). It only activates when CLR_CMAKE_TARGET_OS=android + CLR_CMAKE_TARGET_ARCH=arm, leaving all other targets unaffected.

Package authoring no longer needed in .NET 9

IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older versions.

[jakobbotsch]

Let's see how this works out... I don't think we ever tested the softfp support in our own CI, and this support was added many years ago by Samsung, so it may be quite bitrotted at this point.
I do think they have been using the armel support since then, so it may not be too bad.

[mangod9]

It appears the DateTime issue is resolved but there are other failures with that leg. Dont think android-arm on coreclr is ready to be in CI yet. The change should be reverted till the leg is validated for longer @simonrozsival ?

[simonrozsival]

Dont think android-arm on coreclr is ready to be in CI yet.

@mangod9 I agree. #127225 was merged without adequate validation. Reverting in #127547.

[mangod9]

Closing this since the android-arm PR is reverted. This change might be needed before enabling again, but appears it needs other investigations to enable.

[Copilot]

Android armeabi-v7a mandates the softfp calling convention (-mfloat-abi=softfp): float args pass through integer registers at call boundaries even though VFP is used for arithmetic. After #127225 enabled RyuJIT for android-arm, the JIT was never told to use softfp, so it treated the ABI as hardfp. Math.Truncate calls ModF(d, &d) — but with no stack slot allocated for d (it lives in d0), &d is null → SIGSEGV before any test runs.

Description

• eng/native/configureplatform.cmake: Set ARM_SOFTFP=1 when CLR_CMAKE_TARGET_ARCH=arm and CLR_CMAKE_TARGET_OS=android. This feeds into the existing configurecompiler.cmake path that globally emits -DARM_SOFTFP and -mfloat-abi=softfp, aligning the JIT's codegen ABI assumptions with the NDK default.

• src/coreclr/clrdefinitions.cmake: Extend the ARM_SOFTFPtarget_compile_definitions in set_target_definitions_to_custom_os_and_arch to also cover arch=arm when CLR_CMAKE_TARGET_ANDROID is set. This ensures JIT/gcinfo cross-compilation targets get the correct define.

# Before: only armel (soft-float embedded Linux) got ARM_SOFTFPif (TARGETDETAILS_ARCH STREQUAL"armel")
# After: Android ARM32 also needs softfpif (TARGETDETAILS_ARCH STREQUAL"armel"OR
(TARGETDETAILS_ARCH STREQUAL"arm"AND CLR_CMAKE_TARGET_ANDROID))

Customer Impact

Hard crash (SIGSEGV) on startup of any .NET app running on Android ARM32 with the CoreCLR runtime. Affects every test leg on android-arm, blocking all PRs that trigger those legs.

Regression

Yes — introduced by #127225 (merged 2026-04-28) which first enabled the CoreCLR JIT on android-arm. No prior release shipped android-arm CoreCLR support, so no stable release is affected.

Testing

The fix is build-system / compile-flag only. Correctness is validated by the android-arm CI leg added in #127225 — the SIGSEGV crash on DateTime.get_Now() during test runner init will no longer occur once the JIT correctly spills float parameters to stack slots.

Risk

Low. The change mirrors exactly what is already done for armel (soft-float embedded Linux). It only activates when CLR_CMAKE_TARGET_OS=android + CLR_CMAKE_TARGET_ARCH=arm, leaving all other targets unaffected.

Package authoring no longer needed in .NET 9

IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older versions.

[jakobbotsch]

Let's see how this works out... I don't think we ever tested the softfp support in our own CI, and this support was added many years ago by Samsung, so it may be quite bitrotted at this point.
I do think they have been using the armel support since then, so it may not be too bad.

[mangod9]

It appears the DateTime issue is resolved but there are other failures with that leg. Dont think android-arm on coreclr is ready to be in CI yet. The change should be reverted till the leg is validated for longer @simonrozsival ?

[simonrozsival]

Dont think android-arm on coreclr is ready to be in CI yet.

@mangod9 I agree. #127225 was merged without adequate validation. Reverting in #127547.

[mangod9]

Closing this since the android-arm PR is reverted. This change might be needed before enabling again, but appears it needs other investigations to enable.