Add basic support for compiling to ARM32 #1294

kant2002 · 2021-07-03T13:58:20Z

This is what I do to make it compile on Raspbian on my Raspberry Pi 3B+

GcProbe.S is just copy from ARM64
__cdecl is not defined on ARM, so I suppress that
I resurrect RareFlags from CoreRT in hopes that this is make it works, but no luck
I try to resurrect dotnet/corert@d9847af in changes to regdisp.h but seems to be I do wrong thing here, and I should resurrect definitions from there.

I would like to understand is RareFlags are still valid way, and if not what's the proper way.

See #833

jkotas · 2021-07-03T15:38:47Z

What do you need the rare flags for?

jkotas · 2021-07-03T15:43:09Z

src/coreclr/nativeaot/Runtime/PalRedhawk.h

@@ -647,7 +647,9 @@ inline uint8_t * PalNtCurrentTeb()
 // conditional compilation (upto and including defining an export of functionality that isn't a supported
 // intrinsic on that platform).
 //
-
+#if defined(HOST_ARM)
+#define __cdecl


Where do the other architectures (x64 or arm64) get the cdecl from?

I assume this is MSVC specific calling convention, and probably this code was never compiled on non-Windows.

I assume that mean I cannot find anything which make me think otherwise. I looking for gcc and clang but seems to be it's only MSVC specific

Right, this file is included for Linux x64 or arm64 as well. Why is clang not complaining about this cdecl on existing Linux targets?

This is what I still cannot get where this is included.
I found following 3 files where __cdecl is redefined if needed

src\coreclr\pal\inc\pal_mstypes.h src\coreclr\inc\palclr.h src\coreclr\inc\coredistools.h

Last one seems to be not connected to building Runtime/Full, but other two can be somehow included. I try to track down

I will continue hunt down, since on my Linux arm64 with command ./build.sh nativeaot -a arm64 -rc Debug -lc Release I pass that point, so somewhere I should change macro conditions.

Side-node: Not sure if this is expected,

error MSB3030: Could not copy the file "~/runtimelab/artifacts/bin/coreclr/Linux.arm64.Debug/libjitinterface_arm64.so" because it was not found. [/~/runtimelab/src/coreclr/tools/aot/ILCompiler/ILCompiler.csproj]```

Could not copy the file "~/runtimelab/artifacts/bin/coreclr/Linux.arm64.Debug/libjitinterface_arm64.so"

It is not expected. We do official arm64 builds via cross-compilation on Linux x64 so it may explain why we do not see it.

Things become more interesting. It seems that I know the reason why ARM not working.
Difference in compilation flags give me hint to the problem.
ARM

clang test.cpp -lstdc++ -fms-extensions -march=armv7-a

Literally anything else

clang test.cpp -lstdc++ -fms-extensions

Irregardless of -march presence it produce warning on ARM, and only way to suppress that is to undefine __cdecl.
So options are following:

Should I place __cdecl augmentation in the src/coreclr/nativeaot/Runtime/PalRedhawk.h or src/coreclr/nativeaot/Runtime/PalRedhawkCommon.h

Or maybe I can include src\coreclr\pal\inc\pal_mstypes.h or src\coreclr\inc\palclr.h in PalRedhawkXXX.h

Should I place __cdecl augmentation in the src/coreclr/nativeaot/Runtime/PalRedhawk.h or src/coreclr/nativeaot/Runtime/PalRedhawkCommon.h

Yes, that sounds good.

src/coreclr/inc/regdisp.h

kant2002 · 2021-07-03T17:59:23Z

This is most puzzling thing for me. I notice that this is missing between CoreRT and NativeAOT. Actual copy start after I hit compilation errors here

runtimelab/src/coreclr/nativeaot/Runtime/RuntimeInstance.cpp

Lines 449 to 459 in e8ca007

    
           #ifdef HOST_ARM 
        
                   if ((pEEType->get_RareFlags() & EEType::RareFlags::RequiresAlign8Flag) == EEType::RareFlags::RequiresAlign8Flag) 
        
                   { 
        
                       if (pEEType->HasFinalizer()) 
        
                           return INDIRECTION(RhpNewFinalizableAlign8); 
        
                       else if (pEEType->get_IsValueType())            // returns true for enum types as well 
        
                           return INDIRECTION(RhpNewFastMisalign); 
        
                       else 
        
                           return INDIRECTION(RhpNewFastAlign8); 
        
                   } 
        
           #endif

This was only place where RareFlags was used. Sorry that I forgot to mention that in the original issue description. Whole PR is more question, then actual work.

kant2002 · 2021-07-05T06:49:25Z

When building using on x64 Linux with command line ./build.sh nativeaot -a arm -rc Debug -lc Release

error produced

~/runtimelab/.dotnet/sdk/6.0.100-preview.4.21255.9/Microsoft.Common.CurrentVersion.targets(4964,5): error MSB3030: Could not copy the file "~/.nuget/packages/runtime.linux-arm.microsoft.dotnet.ilcompiler/6.0.0-preview.5.21222.2/tools/libobjwriter.so" because it was not found. [~/runtimelab/src/coreclr/tools/aot/ILCompiler/ILCompiler.csproj]
~/runtimelab/.dotnet/sdk/6.0.100-preview.4.21255.9/Microsoft.Common.CurrentVersion.targets(4964,5): error MSB3030: Could not copy the file "~/runtimelab/artifacts/bin/coreclr/Linux.arm.Debug/libjitinterface_arm.so" because it was not found. [~/runtimelab/src/coreclr/tools/aot/ILCompiler/ILCompiler.csproj]```
I assume that `libjitinterface_arm` this is 2 separate issues
- package `runtime.linux-arm.microsoft.dotnet.ilcompiler` does not produced (there nothing I can do now), and
- `libjitinterface_arm` does not built as part of product build. This one I have to look. Need a bit of time to get inside build system.

jkotas · 2021-07-06T03:17:45Z

src/coreclr/inc/regdisp.h

@@ -155,7 +155,7 @@ inline TADDR GetRegdisplayStackMark(REGDISPLAY *display) {

 #elif defined(TARGET_64BIT)

-#if defined(TARGET_ARM64)
+#if defined(TARGET_ARM64) || defined(TARGET_ARM)


This does not look right. TARGET_64BIT above should not be defined for TARGET_ARM. 32-bit ARM has very different volatile context pointers.

jkotas · 2021-07-06T03:24:14Z

This was only place where RareFlags was used.

We should rewrite this in C#. The extra indirection is not needed anymore, so this should just directly return the function pointer.

kant2002 · 2021-07-06T13:44:16Z

We should rewrite this in C#. The extra indirection is not needed anymore, so this should just directly return the function pointer.

@jkotas is this related to this whole function, or to only offending part?

jkotas · 2021-07-06T14:46:13Z

@jkotas is this related to this whole function, or to only offending part?

The whole function

src/coreclr/nativeaot/Runtime/RuntimeInstance.cpp

jkotas

This looks good to me as is. Is it fine to merge? (The PR is still marked [DRAFT].)

kant2002 · 2021-07-09T03:08:05Z

This is still draft. I have other recommendations replace with C# and most likely this is requirement. That’s another can of worm for me. I can show want I have because I only barely understand what’s going on yet.

…

On Fri, Jul 9, 2021 at 06:39 Jan Kotas ***@***.***> wrote: ***@***.**** approved this pull request. This looks good to me as is. Is it fine to merge? (The PR is still marked [DRAFT].) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1294 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABAPKN6PWLSPNAOK4JQJXALTWZANLANCNFSM47YFKUEQ> .

jkotas · 2021-07-09T05:33:47Z

I have other recommendations replace with C#

It is fine to do that in separate PR. This PR is a good incremental step in its current state. I would be happy to merge it if you drop "DRAFT" from the title.

kant2002 · 2021-07-09T05:38:33Z

This is not yet compiling. Given that it was broken, I would not mind, but maybe not what you expect.

kant2002 · 2021-07-09T05:39:51Z

But I'm more then happy with that, since I working on update libunwind, so I let it hang until you merge that PR then. And really rework of RhGetRuntimeHelperForType would be huge toll on me.

jkotas · 2021-07-09T05:50:23Z

Thank you!

When I copy over that file, I do not realize that these 2 functions was already declared in GcProbe.asm and this file needed only for build system. So far left following - Produce libObjWriter.so for ARM - Rewrite RhGetRuntimeHelperForType in C# as per this discussion dotnet#1294 (comment)

jkotas reviewed Jul 3, 2021

View reviewed changes

src/coreclr/inc/regdisp.h Outdated Show resolved Hide resolved

jkotas reviewed Jul 6, 2021

View reviewed changes

Reduce not needed code

e4ebaf3

kant2002 force-pushed the kant/add-arm branch from ef7ef69 to e4ebaf3 Compare July 6, 2021 07:44

Add __cdecl definition

6b723cc

kant2002 commented Jul 8, 2021

View reviewed changes

src/coreclr/nativeaot/Runtime/RuntimeInstance.cpp Show resolved Hide resolved

jkotas approved these changes Jul 9, 2021

View reviewed changes

kant2002 changed the title ~~[DRAFT] Add basic support for compiling to ARM32 (?)~~ Add basic support for compiling to ARM32 Jul 9, 2021

jkotas merged commit 232cc42 into dotnet:feature/NativeAOT Jul 9, 2021

kant2002 deleted the kant/add-arm branch July 9, 2021 05:51

This was referenced Jul 26, 2021

Fix assembly on ARM32 #1362

Merged

Rework RhGetRuntimeHelperForType in C# #1371

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add basic support for compiling to ARM32 #1294

Add basic support for compiling to ARM32 #1294

kant2002 commented Jul 3, 2021

jkotas commented Jul 3, 2021

jkotas Jul 3, 2021

kant2002 Jul 3, 2021

kant2002 Jul 5, 2021

jkotas Jul 6, 2021

kant2002 Jul 6, 2021

jkotas Jul 6, 2021

kant2002 Jul 6, 2021

jkotas Jul 6, 2021

kant2002 commented Jul 3, 2021

kant2002 commented Jul 5, 2021

jkotas Jul 6, 2021

jkotas commented Jul 6, 2021

kant2002 commented Jul 6, 2021

jkotas commented Jul 6, 2021

jkotas left a comment

kant2002 commented Jul 9, 2021 via email

jkotas commented Jul 9, 2021

kant2002 commented Jul 9, 2021

kant2002 commented Jul 9, 2021

jkotas commented Jul 9, 2021

Add basic support for compiling to ARM32 #1294

Add basic support for compiling to ARM32 #1294

Conversation

kant2002 commented Jul 3, 2021

jkotas commented Jul 3, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kant2002 commented Jul 3, 2021

kant2002 commented Jul 5, 2021

Choose a reason for hiding this comment

jkotas commented Jul 6, 2021

kant2002 commented Jul 6, 2021

jkotas commented Jul 6, 2021

jkotas left a comment

Choose a reason for hiding this comment

kant2002 commented Jul 9, 2021 via email

jkotas commented Jul 9, 2021

kant2002 commented Jul 9, 2021

kant2002 commented Jul 9, 2021

jkotas commented Jul 9, 2021