Update issue number for async testing on arm64

[MichalStrehovsky]

This one is also presumably fixed.

Cc @dotnet/ilc-contrib

[MichalStrehovsky]

/azp run runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR removes a workaround that disabled async testing for NativeAOT on arm64 architecture, presumably because the underlying issue (#121878) has been fixed.

• Removes the conditional property group that set DisableProjectBuild for NativeAOT on arm64
• Enables previously disabled async tests to run on arm64 with NativeAOT

---

You can also share your feedback on Copilot code review for a chance to win a $100 gift card. Take the survey.

[am11]

##[error]ld.lld(0,0): error : relocation R_AARCH64_ABS64 cannot be used against symbol 'Internal_CompilerGenerated__Module___<Resume>valuetask_source_Async2ValueTaskSource__<AsyncCallable>valuetask_source_Async2ValueTaskSource__AwaitConfigDefault'; recompile with -fPIC [/__w/1/s/src/tests/async/valuetask-source/valuetask-source.csproj]
ld.lld : error : relocation R_AARCH64_ABS64 cannot be used against symbol 'Internal_CompilerGenerated__Module___<Resume>valuetask_source_Async2ValueTaskSource__<AsyncCallable>valuetask_source_Async2ValueTaskSource__AwaitConfigDefault'; recompile with -fPIC [/__w/1/s/src/tests/async/valuetask-source/valuetask-source.csproj] [/__w/1/s/src/tests/build.proj]
    >>> defined in /__w/1/s/artifacts/tests/coreclr/obj/linux.arm64.Checked/Managed/async/valuetask-source/valuetask-source/native/valuetask-source.o
    >>> referenced by valuetask-source.cs:134 (/__w/1/s/src/tests/async/valuetask-source/valuetask-source.cs:134)
    >>>               /__w/1/s/artifacts/tests/coreclr/obj/linux.arm64.Checked/Managed/async/valuetask-source/valuetask-source/native/valuetask-source.o:(valuetask_source_Async2ValueTaskSource__<AsyncCallable>valuetask_source_Async2ValueTaskSource__AwaitConfigDefault)

I think it should follow the same R_AARCH64_TLSDESC_* pattern for TLS linker magic but genCodeForAsyncContinuation/genReturnSuspend are recording different relocs?

runtime/src/coreclr/jit/codegenarmarch.cpp

Lines 3339 to 3349 in 3b3270b

	// For NativeAOT, linux/arm64, linker wants the following pattern, so we will generate
	// it as part of the call. Generating individual instructions is tricky to get it
	// correct in the format the way linker needs. Also, we might end up spilling or
	// reloading a register, which can break the pattern.
	//
	// mrs x1, tpidr_el0
	// adrp x0, :tlsdesc:tlsRoot ; R_AARCH64_TLSDESC_ADR_PAGE21
	// ldr x2, [x0] ; R_AARCH64_TLSDESC_LD64_LO12
	// add x0, x0, #0 ; R_AARCH64_TLSDESC_ADD_LO12
	// blr x2 ; R_AARCH64_TLSDESC_CALL
	// add x0, x1, x0

[am11]

Ah, it will probably need #121871 fixed, interesting that x86_64 was fixed by your workaround but not arm64:

runtime/src/coreclr/tools/Common/Compiler/DependencyAnalysis/MethodReadOnlyDataNode.cs

Line 29 in 3b3270b

// TODO: (async) This should stay RO everywhere: https://github.com/dotnet/runtime/issues/121871

(riscv64 and loongarch64 are failing on the similar reloc issue in my local branch when I added handler for GT_ASYNC_CONTINUATION and GT_RETURN_SUSPEND cases)

[MichalStrehovsky]

Ah, it will probably need #121871 fixed, interesting that x86_64 was fixed by your workaround but not arm64:

This looks like a separate issue. From what I'm seeing here, we're ending up with some R_AARCH64_ABS64 relocations in the TEXT section. Looks like ELF doesn't like that either. If I'm reading this right, there seems to be some extra data right after an asynccallable method body:

Here are the relocs in the object file:

0000000994b8  009c00000101 R_AARCH64_ABS64   0000000000098a40 Internal_Compiler[...] + 0
0000000994c0  2f6b00000101 R_AARCH64_ABS64   0000000000099390 testing_Program__[...] + 90

Here's the disassembly:

   994ac: f9400ff3     	ldr	x19, [sp, #0x18]
   994b0: a8c27bfd     	ldp	x29, x30, [sp], #0x20
   994b4: d65f03c0     	ret
		...

00000000000994d0 <testing_Foo__<AsyncCallable>testing_Foo__Yep>:
   994d0: a9bd7bfd     	stp	x29, x30, [sp, #-0x30]!

Looks like the relocs are applied to something between these two methods. @jakobbotsch does this ring a bell?

[jakobbotsch]

Ah, it will probably need #121871 fixed, interesting that x86_64 was fixed by your workaround but not arm64:

This looks like a separate issue. From what I'm seeing here, we're ending up with some R_AARCH64_ABS64 relocations in the TEXT section. Looks like ELF doesn't like that either. If I'm reading this right, there seems to be some extra data right after an asynccallable method body:

Here are the relocs in the object file:

0000000994b8  009c00000101 R_AARCH64_ABS64   0000000000098a40 Internal_Compiler[...] + 0
0000000994c0  2f6b00000101 R_AARCH64_ABS64   0000000000099390 testing_Program__[...] + 90

Here's the disassembly:

   994ac: f9400ff3     	ldr	x19, [sp, #0x18]
   994b0: a8c27bfd     	ldp	x29, x30, [sp], #0x20
   994b4: d65f03c0     	ret
		...

00000000000994d0 <testing_Foo__<AsyncCallable>testing_Foo__Yep>:
   994d0: a9bd7bfd     	stp	x29, x30, [sp, #-0x30]!

Looks like the relocs are applied to something between these two methods. @jakobbotsch does this ring a bell?

The JIT places the RO data blob as part of the code blob for these targets:

runtime/src/coreclr/jit/ee_il_dll.cpp

Lines 1148 to 1165 in 7da7284

	#if defined(TARGET_ARM64) || defined(TARGET_LOONGARCH64) || defined(TARGET_RISCV64)
	// For arm64/LoongArch64/RISCV64, we want to allocate JIT data always adjacent to code similar to what native
	// compiler does.
	// This way allows us to use a single `ldr` to access such data like float constant/jmp table.
	// For LoongArch64 using `pcaddi + ld` to access such data.
	UNATIVE_OFFSET roDataAlignmentDelta = 0;
	if (args->roDataSize > 0)
	{
	roDataAlignmentDelta = AlignmentPad(args->hotCodeSize, roDataSectionAlignment);
	}
	const UNATIVE_OFFSET roDataOffset = args->hotCodeSize + roDataAlignmentDelta;
	args->hotCodeSize = roDataOffset + args->roDataSize;
	args->roDataSize = 0;
	#endif // defined(TARGET_ARM64) || defined(TARGET_LOONGARCH64) || defined(TARGET_RISCV64)

[MichalStrehovsky]

The JIT places the RO data blob as part of the code blob for these targets:

Ah. Would that be resolved with #121871 or would we need yet another thing for these platforms? (Whether to just update the issue number that this PR is touching to #121871 or we need a separate issue number?)

[jakobbotsch]

The JIT places the RO data blob as part of the code blob for these targets:

Ah. Would that be resolved with #121871 or would we need yet another thing for these platforms? (Whether to just update the issue number that this PR is touching to #121871 or we need a separate issue number?)

I would expect it to be resolved at the same time.