Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Strip CPPCODEGEN #21

Merged
merged 2 commits into from
Jul 23, 2020
Merged

Strip CPPCODEGEN #21

merged 2 commits into from
Jul 23, 2020

Conversation

jkotas
Copy link
Member

@jkotas jkotas commented Jul 22, 2020

No description provided.

MichalStrehovsky
MichalStrehovsky reviewed Jul 22, 2020
View reviewed changes
src/coreclr/src/nativeaot/Bootstrap/main.cpp
return pString;
}

#if defined(HOST_WASM)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I never realized that, but WASM builds against bootstrappercpp.a, so these CPPCODEGEN ifdefs also apply to WASM :(.

We'll need to decouple that to keep HOST_WASM.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the approach we should take is to delete this cruft as we run into it in NativeAOT branch, and then rewind it as necessary in the eventual wasm branch.

@MichalStrehovsky MichalStrehovsky merged commit 7ef548e into dotnet:NativeAOT Jul 23, 2020
@jkotas jkotas added the area-NativeAOT-coreclr .NET runtime optimized for ahead of time compilation label Jul 25, 2020
@jkotas jkotas deleted the cppcodegen branch August 1, 2020 05:49
MichalStrehovsky added a commit to MichalStrehovsky/runtimelab that referenced this pull request Aug 28, 2020
@MichalStrehovsky
Make it possible to link NativeAOT outputs
9d2814a 
Fixes issues with missing symbols.

Take out a piece of the type loader that requires System.Private.TypeLoader.Native that we didn't bring over for now.

isa_detection.cpp doesn't build in NativeAOT because it doesn't include any headers that would define things like WszLoadLibraryEx or LOAD_LIBRARY_SEARCH_SYSTEM32. It feels like this needs to be factored to use GCToOSInterface but this is not my area of expertise.

Remove reference to __fail_fast that was deleted as part of getting rid of cppcodegen in dotnet#21.
@MichalStrehovsky MichalStrehovsky mentioned this pull request Aug 28, 2020
Merged
MichalStrehovsky added a commit that referenced this pull request Aug 28, 2020
@MichalStrehovsky
Make it possible to link NativeAOT outputs (#72)
91d202f 
Fixes issues with missing symbols.

Take out a piece of the type loader that requires System.Private.TypeLoader.Native that we didn't bring over for now.

isa_detection.cpp doesn't build in NativeAOT because it doesn't include any headers that would define things like WszLoadLibraryEx or LOAD_LIBRARY_SEARCH_SYSTEM32. It feels like this needs to be factored to use GCToOSInterface but this is not my area of expertise.

Remove reference to __fail_fast that was deleted as part of getting rid of cppcodegen in #21.
MichalStrehovsky added a commit to MichalStrehovsky/runtimelab that referenced this pull request Aug 31, 2020
@MichalStrehovsky
Fix linking the outputs of the compilation
4dc6bb7 
Before this change, running link.exe on the output of the compilation produced `LINK : fatal error LNK1561: entry point must be defined`.

This took longer to figure out than I would be willing to admit.

There are two things at play - linker uses the presence of a method named `main` or `wmain` to choose between setting `wmainCRTStartup` or `mainCRTStartup` as the actual entrypoint of the application (C apps don't start with `main` - they start in the C runtime library that calls `main`).

In dotnet#21 we deleted the `__fail_fast` method from main.cpp and then in dotnet#72 we also removed the compiler reference to the now non-existent symbol. The obscure result of that was that main.obj stopped being part of the linking set because nothing now references symbols from it. When linker looks for `main` or `wmain`, it only looks at object files that are already part of the linking set.

As a result, linker didn't inject `wmainCRTStartup` as the entrypoint and we failed with the above message.

It looks like the only way out is to hardcode the CRT implementation detail here. We were already hardcoding it, but for other reasons.

We also need to set the subsystem since the autodetection is failing.
@MichalStrehovsky MichalStrehovsky mentioned this pull request Aug 31, 2020
Merged
jkotas pushed a commit that referenced this pull request Aug 31, 2020
@MichalStrehovsky
Fix linking the outputs of the compilation (#76)
a19596e 
Before this change, running link.exe on the output of the compilation produced `LINK : fatal error LNK1561: entry point must be defined`.

This took longer to figure out than I would be willing to admit.

There are two things at play - linker uses the presence of a method named `main` or `wmain` to choose between setting `wmainCRTStartup` or `mainCRTStartup` as the actual entrypoint of the application (C apps don't start with `main` - they start in the C runtime library that calls `main`).

In #21 we deleted the `__fail_fast` method from main.cpp and then in #72 we also removed the compiler reference to the now non-existent symbol. The obscure result of that was that main.obj stopped being part of the linking set because nothing now references symbols from it. When linker looks for `main` or `wmain`, it only looks at object files that are already part of the linking set.

As a result, linker didn't inject `wmainCRTStartup` as the entrypoint and we failed with the above message.

It looks like the only way out is to hardcode the CRT implementation detail here. We were already hardcoding it, but for other reasons.

We also need to set the subsystem since the autodetection is failing.
jkotas pushed a commit to jkotas/runtimelab that referenced this pull request Sep 13, 2020
@RalfKornmannEnvision @jkotas
ARM64: optimize PREPARE_EXTERNAL:VAR (dotnet#21) (#8296)
783231a 
There are multiple cases were we don't need just the pointer for an external variable but the value that is stored at this location.
So far this was done with the PREPARE_EXTERNAL_VAR followed by an ldr x? [x?]. The PREPARE_EXTERNAL_VAR macro needs two instructions (adrp + add). As the ldr instruction supports an offset we can eliminate the add for this use case. The two new macros PREPARE_EXTERNAL_VAR_INDIRECT and PREPARE_EXTERNAL_VAR_INDIRECT_W make use of this.
jkotas pushed a commit to jkotas/runtimelab that referenced this pull request Sep 13, 2020
@RalfKornmannEnvision @jkotas
ARM64: optimize PREPARE_EXTERNAL:VAR (dotnet#21) (#8296)
326a7fc 
There are multiple cases were we don't need just the pointer for an external variable but the value that is stored at this location.
So far this was done with the PREPARE_EXTERNAL_VAR followed by an ldr x? [x?]. The PREPARE_EXTERNAL_VAR macro needs two instructions (adrp + add). As the ldr instruction supports an offset we can eliminate the add for this use case. The two new macros PREPARE_EXTERNAL_VAR_INDIRECT and PREPARE_EXTERNAL_VAR_INDIRECT_W make use of this.
jkotas pushed a commit that referenced this pull request Sep 13, 2020
@RalfKornmannEnvision @jkotas
ARM64: optimize PREPARE_EXTERNAL:VAR (#21) (#8296)
86e99b4 
There are multiple cases were we don't need just the pointer for an external variable but the value that is stored at this location.
So far this was done with the PREPARE_EXTERNAL_VAR followed by an ldr x? [x?]. The PREPARE_EXTERNAL_VAR macro needs two instructions (adrp + add). As the ldr instruction supports an offset we can eliminate the add for this use case. The two new macros PREPARE_EXTERNAL_VAR_INDIRECT and PREPARE_EXTERNAL_VAR_INDIRECT_W make use of this.
@dlewis-arcontech dlewis-arcontech mentioned this pull request Feb 19, 2021
Closed
runtimelab-bot pushed a commit that referenced this pull request May 18, 2021
@lambdageek
[reflection] Add GC Unsafe transitions on embedding API functions (#5…
d59db3b 
…2769)

Transition to GC Unsafe mode on every MONO_RT_EXTERNAL_ONLY function in
reflection.c

In particular, fix mono_reflection_type_from_name which is used in
https://github.com/xamarin/xamarin-android/blob/681887ebdbd192ce7ce1cd02221d4939599ba762/src/monodroid/jni/embedded-assemblies.cc#L350

Fixes stack traces like

```
05-14 08:06:12.848 31274 31274 F DEBUG   :       #00 pc 00000b99  [vdso] (__kernel_vsyscall+9)
05-14 08:06:12.848 31274 31274 F DEBUG   :       #1 pc 0005ad68  /apex/com.android.runtime/lib/bionic/libc.so (syscall+40) (BuildId: 6e3a0180fa6637b68c0d181c343e6806)
05-14 08:06:12.848 31274 31274 F DEBUG   :       #2 pc 00076511  /apex/com.android.runtime/lib/bionic/libc.so (abort+209) (BuildId: 6e3a0180fa6637b68c0d181c343e6806)
05-14 08:06:12.848 31274 31274 F DEBUG   :       #3 pc 0002afcd  /data/app/~~rMrkpKmVPaBpM5jKb8fPAg==/com.microsoft.maui-JfRo8RWSDJaNtJuBa0y7_Q==/lib/x86/libmonodroid.so (xamarin::android::internal::MonodroidRuntime::mono_log_handler(char const*, char const*, char const*, int, void*)+141) (BuildId: 9726f32ad5f8fa5e7c5762baf2f6e3294da41cc1)
05-14 08:06:12.848 31274 31274 F DEBUG   :       #4 pc 00112c5d  /data/app/~~rMrkpKmVPaBpM5jKb8fPAg==/com.microsoft.maui-JfRo8RWSDJaNtJuBa0y7_Q==/lib/x86/libmonosgen-2.0.so (eglib_log_adapter+141) (BuildId: b67e93dd750dafdd6f65f408b021b6a3a74868ac)
05-14 08:06:12.849 31274 31274 F DEBUG   :       #5 pc 00020fdf  /data/app/~~rMrkpKmVPaBpM5jKb8fPAg==/com.microsoft.maui-JfRo8RWSDJaNtJuBa0y7_Q==/lib/x86/libmonosgen-2.0.so (monoeg_g_logv+175) (BuildId: b67e93dd750dafdd6f65f408b021b6a3a74868ac)
05-14 08:06:12.849 31274 31274 F DEBUG   :       #6 pc 0002113a  /data/app/~~rMrkpKmVPaBpM5jKb8fPAg==/com.microsoft.maui-JfRo8RWSDJaNtJuBa0y7_Q==/lib/x86/libmonosgen-2.0.so (monoeg_g_log+42) (BuildId: b67e93dd750dafdd6f65f408b021b6a3a74868ac)
05-14 08:06:12.849 31274 31274 F DEBUG   :       #7 pc 00128892  /data/app/~~rMrkpKmVPaBpM5jKb8fPAg==/com.microsoft.maui-JfRo8RWSDJaNtJuBa0y7_Q==/lib/x86/libmonosgen-2.0.so (mono_threads_transition_do_blocking+258) (BuildId: b67e93dd750dafdd6f65f408b021b6a3a74868ac)
05-14 08:06:12.849 31274 31274 F DEBUG   :       #8 pc 0012a406  /data/app/~~rMrkpKmVPaBpM5jKb8fPAg==/com.microsoft.maui-JfRo8RWSDJaNtJuBa0y7_Q==/lib/x86/libmonosgen-2.0.so (mono_threads_enter_gc_safe_region_unbalanced_with_info+134) (BuildId: b67e93dd750dafdd6f65f408b021b6a3a74868ac)
05-14 08:06:12.849 31274 31274 F DEBUG   :       #9 pc 0012a27e  /data/app/~~rMrkpKmVPaBpM5jKb8fPAg==/com.microsoft.maui-JfRo8RWSDJaNtJuBa0y7_Q==/lib/x86/libmonosgen-2.0.so (mono_threads_enter_gc_safe_region_internal+46) (BuildId: b67e93dd750dafdd6f65f408b021b6a3a74868ac)
05-14 08:06:12.849 31274 31274 F DEBUG   :       #10 pc 000799a7  /data/app/~~rMrkpKmVPaBpM5jKb8fPAg==/com.microsoft.maui-JfRo8RWSDJaNtJuBa0y7_Q==/lib/x86/libmonosgen-2.0.so (mono_loader_lock+71) (BuildId: b67e93dd750dafdd6f65f408b021b6a3a74868ac)
05-14 08:06:12.849 31274 31274 F DEBUG   :       #11 pc 000447a1  /data/app/~~rMrkpKmVPaBpM5jKb8fPAg==/com.microsoft.maui-JfRo8RWSDJaNtJuBa0y7_Q==/lib/x86/libmonosgen-2.0.so (mono_class_create_from_typedef+129) (BuildId: b67e93dd750dafdd6f65f408b021b6a3a74868ac)
05-14 08:06:12.849 31274 31274 F DEBUG   :       #12 pc 0003c073  /data/app/~~rMrkpKmVPaBpM5jKb8fPAg==/com.microsoft.maui-JfRo8RWSDJaNtJuBa0y7_Q==/lib/x86/libmonosgen-2.0.so (mono_class_get_checked+99) (BuildId: b67e93dd750dafdd6f65f408b021b6a3a74868ac)
05-14 08:06:12.849 31274 31274 F DEBUG   :       #13 pc 0003cc0f  /data/app/~~rMrkpKmVPaBpM5jKb8fPAg==/com.microsoft.maui-JfRo8RWSDJaNtJuBa0y7_Q==/lib/x86/libmonosgen-2.0.so (mono_class_from_name_checked_aux+735) (BuildId: b67e93dd750dafdd6f65f408b021b6a3a74868ac)
05-14 08:06:12.849 31274 31274 F DEBUG   :       #14 pc 00037989  /data/app/~~rMrkpKmVPaBpM5jKb8fPAg==/com.microsoft.maui-JfRo8RWSDJaNtJuBa0y7_Q==/lib/x86/libmonosgen-2.0.so (mono_class_from_name_checked+73) (BuildId: b67e93dd750dafdd6f65f408b021b6a3a74868ac)
05-14 08:06:12.849 31274 31274 F DEBUG   :       #15 pc 000cc5f4  /data/app/~~rMrkpKmVPaBpM5jKb8fPAg==/com.microsoft.maui-JfRo8RWSDJaNtJuBa0y7_Q==/lib/x86/libmonosgen-2.0.so (mono_reflection_get_type_internal+132) (BuildId: b67e93dd750dafdd6f65f408b021b6a3a74868ac)
05-14 08:06:12.849 31274 31274 F DEBUG   :       #16 pc 000c9bce  /data/app/~~rMrkpKmVPaBpM5jKb8fPAg==/com.microsoft.maui-JfRo8RWSDJaNtJuBa0y7_Q==/lib/x86/libmonosgen-2.0.so (mono_reflection_get_type_with_rootimage+126) (BuildId: b67e93dd750dafdd6f65f408b021b6a3a74868ac)
05-14 08:06:12.849 31274 31274 F DEBUG   :       #17 pc 000ca204  /data/app/~~rMrkpKmVPaBpM5jKb8fPAg==/com.microsoft.maui-JfRo8RWSDJaNtJuBa0y7_Q==/lib/x86/libmonosgen-2.0.so (_mono_reflection_get_type_from_info+292) (BuildId: b67e93dd750dafdd6f65f408b021b6a3a74868ac)
05-14 08:06:12.849 31274 31274 F DEBUG   :       #18 pc 000ca06e  /data/app/~~rMrkpKmVPaBpM5jKb8fPAg==/com.microsoft.maui-JfRo8RWSDJaNtJuBa0y7_Q==/lib/x86/libmonosgen-2.0.so (mono_reflection_type_from_name_checked+334) (BuildId: b67e93dd750dafdd6f65f408b021b6a3a74868ac)
05-14 08:06:12.849 31274 31274 F DEBUG   :       #19 pc 000c9f01  /data/app/~~rMrkpKmVPaBpM5jKb8fPAg==/com.microsoft.maui-JfRo8RWSDJaNtJuBa0y7_Q==/lib/x86/libmonosgen-2.0.so (mono_reflection_type_from_name+49) (BuildId: b67e93dd750dafdd6f65f408b021b6a3a74868ac)
05-14 08:06:12.849 31274 31274 F DEBUG   :       #20 pc 0001b40b  /data/app/~~rMrkpKmVPaBpM5jKb8fPAg==/com.microsoft.maui-JfRo8RWSDJaNtJuBa0y7_Q==/lib/x86/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(char const*)+427) (BuildId: 9726f32ad5f8fa5e7c5762baf2f6e3294da41cc1)
05-14 08:06:12.849 31274 31274 F DEBUG   :       #21 pc 0001b551  /data/app/~~rMrkpKmVPaBpM5jKb8fPAg==/com.microsoft.maui-JfRo8RWSDJaNtJuBa0y7_Q==/lib/x86/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(_MonoString*)+113) (BuildId: 9726f32ad5f8fa5e7c5762baf2f6e3294da41cc1)
05-14 08:06:12.849 31274 31274 F DEBUG   :       #22 pc 000211a7  /data/app/~~rMrkpKmVPaBpM5jKb8fPAg==/com.microsoft.maui-JfRo8RWSDJaNtJuBa0y7_Q==/lib/x86/libmonodroid.so (xamarin::android::internal::MonodroidRuntime::typemap_java_to_managed(_MonoString*)+39) (BuildId: 9726f32ad5f8fa5e7c5762baf2f6e3294da41cc1)
```
MichalStrehovsky added a commit to MichalStrehovsky/runtimelab that referenced this pull request Oct 15, 2021
@MichalStrehovsky
Add TypeSpecification and MethodSpecification (dotnet#21)
984c9f9 
These are pretty boring, but adding them adds more testing opportunities for dotnet#4 since these all have a blob that dotnet#4 should be able to parse/rewrite.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@MichalStrehovsky MichalStrehovsky MichalStrehovsky approved these changes

Assignees
No one assigned
Labels
area-NativeAOT-coreclr .NET runtime optimized for ahead of time compilation
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
2 participants
@jkotas @MichalStrehovsky