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.

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

[wasm][debugger] Add support for getters on value types #1

Closed
wants to merge 458 commits into from

Conversation

radical
Copy link
Owner

@radical radical commented Jul 21, 2020

No description provided.

@radical
Copy link
Owner Author

radical commented Jul 21, 2020

Depends on dotnet#39663

yowl and others added 29 commits July 28, 2020 16:16
Co-authored-by: Adeel Mujahid <adeelbm@outlook.com>
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
…otnet#39182)

* [browser][wasm] Initial addition of configuring request options in Browser WebAssembly

* Fix key code.  Not what was proposed

* Add TryGetValue<TValue> and Set<TValue> as per proposal

* Add missing obsolete attribute

* Address review comments

* Update tests to use Options and not obsolete Properties.

* Implement IDictionary<string, object?> explicitly

* Update tests to use Options and not obsolete Properties.

* Add HttpRequestOptions source to the System.Net.Http.Unit.Tests project to fix build.

* Address review comments - explicit

* Fix build error cannot convert from 'string' to 'System.Net.Http.HttpRequestOptionsKey<object>'

* Add tests for HttpRequestOptions

* Fix test build

* Add special case code for NETFRAMEWORK for API change.

* #endif out of place fix

* #endif out of place fix
…ace (dotnet#40004)

There is no repro for dotnet#38807 at the moment so the related tests have been enabled.
Two tests have been disabled due to PNSE (see dotnet#39346).

Fixes: dotnet#38807 

The test run result: `Tests run: 177, Errors: 0, Failures: 0, Skipped: 0.`
This was already disabled with autotools, but I forgot to update winconfig.h as well.
They are no longer needed after dotnet#38996 since we return values in managed code now.
This fixes an issue where release jits might sometimes generate bad GC info.
Keeping it minimal for now so we can consider servicing preview 8.

See dotnet#39023 for details.
* wip

* split perf jobs into test categories

* add test category to run-performance-job.yml

* correct space

* add space to parameter var

* add $

* fix yaml

* revert extraparameters

* replace crossgen runkind

* change micro_mono tag

* remove space
* Shims

* shim

* Cherry-pick

* NarrowFourUtf16CharsToAsciiAndWriteToBuffer

* Address comments

* Nit
…threads (dotnet#38568)

- When CPU groups are enabled through config, some new threads (Thread.Start, thread pool threads) are automatically assigned to a CPU group, starting with the process' CPU group and once it is filled up, assigning new threads to a different CPU group. An app may have native components that also use threads, and may want to do its own thread-spreading (for instance in DllMain), this config allows such apps to disable the automatic CPU group assignment which would otherwise override an assignment made in DllMain. The new config var does not affect GC threads.
- This was requested for .NET Framework, porting to .NET Core as well
…ossgen2 (dotnet#40096)

- Add a mechanism for passing arbitrary arguments to the crossgen2 process while running crossgen2 tests
- Pass the `--codegenopt JitObjectStackAllocation=1` when compiling this test with Crossgen2. This will result in enabling the object stack allocation feature during compilation
- As Crossgen2 currently disregards the debuggable attribute when deciding codegen mode, detect the presence running crossgen2 and expect allocation to occur on the stack even if S.P.C is debuggable
The optCSEhash can grow an unbounded amount if the function has numerous trees which are put into the optCSEhash as possible CSE candidates, but fewer than MAX_CSE_CNT are found, then the compiler will spend excessive amounts of time looking up entries in the optCSEhash.

This fix addresses the issue by making the optCSEhash able to grow its count of buckets.
Add env var to control createdump on MacOS

The COMPlus_DbgEnableElfDumpOnMacOS needs to be set to 1 along with all the other standard createdump env vars for dumps to be enabled on MacOS.

This is because ELF coredumps are generated on MacOS and we want customers to be very explicit and aware of what the are getting.

Change test harness to use the new env var

Createdump documentation update
If a project that is part of solution has a ProjectReference to CoreLib, the Platform property was set to AnyCPU and CoreLib was built with the wrong Platform/Platform_Target.
Fix the following issues:

    On amd64 linux we didn't save and restore the xmm registers, and didn't handle enregistered 16 bytes structs as return values
    On arm we didn't save and restore the floating point registers (I made the linux arm helpers match the windows arm helpers)
    On arm64 we didn't handle 16 byte enregistered structs as return values

And add tests
radical added 7 commits August 7, 2020 20:26
- this also becomes useful in subsequent commits which enable invoking
getters on valuetypes
- keep a copy of the value bytes, and the klass pointer
- this allows being able to invoke getters on such a valuetype, at a
later point
- This allows getters like `DateTime.Date`, which has the type
`DateTime`
.. and replace `var` with `let`, or `const`, where appropriate.
.. especially the ones that return data in `MONO.var_info`.

To use:

1. `this._register_c_var_fn ('mono_wasm_get_object_properties', 'bool', [ 'number', 'bool' ]);`
2. Now, this function can be called as `this.mono_wasm_get_object_properties_info (.. )`
    - returns `res` which has the contents of `MONO.var_info`, after running
    `_fixup_name_value_objects` on it.
- functions like those for getting object/vt properties, can fail, for
example, if the objectId is invalid.
- We now return that bool result, and that gets surfaced to the caller

- This will also help to differentiate the case where the result of such
a function was a failure vs just an empty result
- These tests don't actually depend on the error message, and we don't
have another to way to differentiate why a command might have failed
with an exception. So, right now, they will pass as long as the commands
fail as expected.

- Future TODO: return `error`, instead of exception details for issues
in `mono.js`, like incorrect input, invalid id etc, and update these
tests accordingly.
@radical radical closed this Sep 1, 2020
radical added a commit that referenced this pull request Apr 5, 2021
```
/_/src/libraries/System.Linq.Expressions/tests/Member/MemberAccessTests.cs(503,82): Trim analysis error IL2103: System.Linq.Expressions.Tests.MemberAccessTests.<>c.<Property_GenericPropertyAccessor_ThrowsArgumentException>b__38_0(): Value passed to the '#1' parameter of method 'System.Linq.Expressions.MemberExpression System.Linq.Expressions.Expression::Property(System.Linq.Expressions.Expression,System.Reflection.MethodInfo)' cannot be statically determined as a property accessor. [/__w/1/s/src/libraries/System.Linq.Expressions/tests/System.Linq.Expressions.Tests.csproj]
/_/src/libraries/System.Linq.Expressions/tests/Member/MemberAccessTests.cs(504,82): Trim analysis error IL2103: System.Linq.Expressions.Tests.MemberAccessTests.<>c.<Property_GenericPropertyAccessor_ThrowsArgumentException>b__38_1(): Value passed to the '#1' parameter of method 'System.Linq.Expressions.MemberExpression System.Linq.Expressions.Expression::Property(System.Linq.Expressions.Expression,System.Reflection.MethodInfo)' cannot be statically determined as a property accessor. [/__w/1/s/src/libraries/System.Linq.Expressions/tests/System.Linq.Expressions.Tests.csproj]
/_/src/libraries/System.Linq.Expressions/tests/Member/MemberAccessTests.cs(459,74): Trim analysis error IL2103: System.Linq.Expressions.Tests.MemberAccessTests.<>c.<Property_InstanceProperty_NullExpression_ThrowsArgumentException>b__33_3(): Value passed to the '#1' parameter of method 'System.Linq.Expressions.MemberExpression System.Linq.Expressions.Expression::Property(System.Linq.Expressions.Expression,System.Reflection.MethodInfo)' cannot be statically determined as a property accessor. [/__w/1/s/src/libraries/System.Linq.Expressions/tests/System.Linq.Expressions.Tests.csproj]
/_/src/libraries/System.Linq.Expressions/tests/Member/MemberAccessTests.cs(511,82): Trim analysis error IL2103: System.Linq.Expressions.Tests.MemberAccessTests.<>c.<Property_PropertyAccessorNotFromProperty_ThrowsArgumentException>b__39_0(): Value passed to the '#1' parameter of method 'System.Linq.Expressions.MemberExpression System.Linq.Expressions.Expression::Property(System.Linq.Expressions.Expression,System.Reflection.MethodInfo)' cannot be statically determined as a property accessor. [/__w/1/s/src/libraries/System.Linq.Expressions/tests/System.Linq.Expressions.Tests.csproj]
/_/src/libraries/System.Linq.Expressions/tests/Member/MemberAccessTests.cs(448,76): Trim analysis error IL2103: System.Linq.Expressions.Tests.MemberAccessTests.<>c__DisplayClass32_0.<Property_StaticProperty_NonNullExpression_ThrowsArgumentException>b__2(): Value passed to the '#1' parameter of method 'System.Linq.Expressions.MemberExpression System.Linq.Expressions.Expression::Property(System.Linq.Expressions.Expression,System.Reflection.MethodInfo)' cannot be statically determined as a property accessor. [/__w/1/s/src/libraries/System.Linq.Expressions/tests/System.Linq.Expressions.Tests.csproj]
/_/src/libraries/System.Linq.Expressions/tests/Member/MemberAccessTests.cs(472,76): Trim analysis error IL2103: System.Linq.Expressions.Tests.MemberAccessTests.<>c__DisplayClass34_0.<Property_ExpressionNotReadable_ThrowsArgumentException>b__3(): Value passed to the '#1' parameter of method 'System.Linq.Expressions.MemberExpression System.Linq.Expressions.Expression::Property(System.Linq.Expressions.Expression,System.Reflection.MethodInfo)' cannot be statically determined as a property accessor. [/__w/1/s/src/libraries/System.Linq.Expressions/tests/System.Linq.Expressions.Tests.csproj]
/_/src/libraries/System.Linq.Expressions/tests/Member/MemberAccessTests.cs(482,74): Trim analysis error IL2103: System.Linq.Expressions.Tests.MemberAccessTests.<>c__DisplayClass35_0.<Property_ExpressionNotTypeOfDeclaringType_ThrowsArgumentException>b__2(): Value passed to the '#1' parameter of method 'System.Linq.Expressions.MemberExpression System.Linq.Expressions.Expression::Property(System.Linq.Expressions.Expression,System.Reflection.MethodInfo)' cannot be statically determined as a property accessor. [/__w/1/s/src/libraries/System.Linq.Expressions/tests/System.Linq.Expressions.Tests.csproj]
```
radical pushed a commit that referenced this pull request May 18, 2021
…tnet#52769)

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)
```
radical pushed a commit that referenced this pull request May 19, 2021
…2915)

* [build] Define NO_UNALIGNED_ACCESS for 32-bit arm platforms

Possibly related to crashes on Android like this:

```
05-18 10:59:07.466 17076 17076 F libc    : Fatal signal 7 (SIGBUS), code 1 (BUS_ADRALN), fault addr 0xb9c95a41 in tid 17076 (simplehellomaui), pid 17076 (simplehellomaui)
05-18 10:59:07.501 17104 17104 I crash_dump32: obtaining output fd from tombstoned, type: kDebuggerdTombstone
05-18 10:59:07.502   989   989 I tombstoned: received crash request for pid 17076
05-18 10:59:07.503 17104 17104 I crash_dump32: performing dump of process 17076 (target tid = 17076)
05-18 10:59:07.512 17104 17104 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
05-18 10:59:07.512 17104 17104 F DEBUG   : Build fingerprint: 'google/crosshatch/crosshatch:11/RQ2A.210405.005/7181113:user/release-keys'
05-18 10:59:07.512 17104 17104 F DEBUG   : Revision: 'MP1.0'
05-18 10:59:07.512 17104 17104 F DEBUG   : ABI: 'arm'
05-18 10:59:07.515 17104 17104 F DEBUG   : Timestamp: 2021-05-18 10:59:07+0200
05-18 10:59:07.515 17104 17104 F DEBUG   : pid: 17076, tid: 17076, name: simplehellomaui  >>> com.microsoft.simplehellomaui <<<
05-18 10:59:07.515 17104 17104 F DEBUG   : uid: 10364
05-18 10:59:07.515 17104 17104 F DEBUG   : signal 7 (SIGBUS), code 1 (BUS_ADRALN), fault addr 0xb9c95a41
05-18 10:59:07.515 17104 17104 F DEBUG   :     r0  bb4a5cd0  r1  b9c95a49  r2  00000000  r3  e94c7520
05-18 10:59:07.515 17104 17104 F DEBUG   :     r4  0000000c  r5  00000000  r6  ff843c50  r7  ff843e70
05-18 10:59:07.515 17104 17104 F DEBUG   :     r8  b69547f8  r9  e99eac50  r10 00000000  r11 00000021
05-18 10:59:07.515 17104 17104 F DEBUG   :     ip  e94c74f0  sp  ff843c48  lr  bb31e0dd  pc  bb3a4d24
05-18 10:59:07.531   709   709 E Layer   : [Surface(name=Task=1)/@0x52e6b1a - animation-leash#0] No local sync point found
05-18 10:59:07.532   709   709 E Layer   : [Surface(name=Task=1571)/@0x9c90165 - animation-leash#0] No local sync point found
05-18 10:59:07.706 17104 17104 F DEBUG   : backtrace:
05-18 10:59:07.707 17104 17104 F DEBUG   :       #00 pc 000ddd24  /data/app/~~J4DFQ3c1v2YGrEurX7TNjg==/com.microsoft.simplehellomaui-_jGGPiZpZ3yT-QCTNDcgvQ==/lib/arm/libmonosgen-2.0.so (mono_method_to_ir+9232) (BuildId: d0a4e41a500357a621884b64f6ca8533b62a664b)
05-18 10:59:07.707 17104 17104 F DEBUG   :       #1 pc 000d7777  /data/app/~~J4DFQ3c1v2YGrEurX7TNjg==/com.microsoft.simplehellomaui-_jGGPiZpZ3yT-QCTNDcgvQ==/lib/arm/libmonosgen-2.0.so (inline_method+622) (BuildId: d0a4e41a500357a621884b64f6ca8533b62a664b)
05-18 10:59:07.707 17104 17104 F DEBUG   :       #2 pc 000ec0a3  /data/app/~~J4DFQ3c1v2YGrEurX7TNjg==/com.microsoft.simplehellomaui-_jGGPiZpZ3yT-QCTNDcgvQ==/lib/arm/libmonosgen-2.0.so (mono_method_to_ir+67470) (BuildId: d0a4e41a500357a621884b64f6ca8533b62a664b)
05-18 10:59:07.707 17104 17104 F DEBUG   :       #3 pc 000cda6d  /data/app/~~J4DFQ3c1v2YGrEurX7TNjg==/com.microsoft.simplehellomaui-_jGGPiZpZ3yT-QCTNDcgvQ==/lib/arm/libmonosgen-2.0.so (mini_method_compile+2264) (BuildId: d0a4e41a500357a621884b64f6ca8533b62a664b)
05-18 10:59:07.707 17104 17104 F DEBUG   :       #4 pc 000cf413  /data/app/~~J4DFQ3c1v2YGrEurX7TNjg==/com.microsoft.simplehellomaui-_jGGPiZpZ3yT-QCTNDcgvQ==/lib/arm/libmonosgen-2.0.so (mono_jit_compile_method_inner+50) (BuildId: d0a4e41a500357a621884b64f6ca8533b62a664b)
05-18 10:59:07.707 17104 17104 F DEBUG   :       #5 pc 000d1d7f  /data/app/~~J4DFQ3c1v2YGrEurX7TNjg==/com.microsoft.simplehellomaui-_jGGPiZpZ3yT-QCTNDcgvQ==/lib/arm/libmonosgen-2.0.so (mono_jit_compile_method_with_opt+1766) (BuildId: d0a4e41a500357a621884b64f6ca8533b62a664b)
05-18 10:59:07.707 17104 17104 F DEBUG   :       #6 pc 0012d94d  /data/app/~~J4DFQ3c1v2YGrEurX7TNjg==/com.microsoft.simplehellomaui-_jGGPiZpZ3yT-QCTNDcgvQ==/lib/arm/libmonosgen-2.0.so (common_call_trampoline+832) (BuildId: d0a4e41a500357a621884b64f6ca8533b62a664b)
05-18 10:59:07.707 17104 17104 F DEBUG   :       #7 pc 0012d5cb  /data/app/~~J4DFQ3c1v2YGrEurX7TNjg==/com.microsoft.simplehellomaui-_jGGPiZpZ3yT-QCTNDcgvQ==/lib/arm/libmonosgen-2.0.so (mono_magic_trampoline+62) (BuildId: d0a4e41a500357a621884b64f6ca8533b62a664b)
05-18 10:59:07.707 17104 17104 F DEBUG   :       #8 pc 0000006a <anonymous:b7986000>
```

* move to host/target sections
radical pushed a commit that referenced this pull request Jul 2, 2021
…et#53792)

I have expanded the PerfMap format produced by Crossgen2 and
R2RDump to produce metadata in form of pseudo-symbol records with
high addresses. In this version I have implemented four metadata
entries - output GUID, target OS, target architecture and perfmap
format version number.  I have verified for System.Private.CoreLib
and for the composite framework that Crossgen2 and R2RDump
produce identical metadata.

To facilitate a smooth transition to the new perfmap format, in
accordance with Juan's suggestion I have introduced a new command-line
option to explicitly specify the perfmap format revision. As of today,
0 corresponds to the legacy Crossgen1-style output where the
perfmap file name includes the {MVID} section, perfmap format #1
corresponds to current Crossgen2 with its new naming scheme.
As of today there are no differences in the file content.

Thanks

Tomas
radical pushed a commit that referenced this pull request Jan 13, 2022
…otnet#63598)

* Fix native frame unwind in syscall on arm64 for VS4Mac crash report.

Add arm64 version of StepWithCompactNoEncoding for syscall leaf node wrappers that have compact encoding of 0.

Fix ReadCompactEncodingRegister so it actually decrements the addr.

Change StepWithCompactEncodingArm64 to match what MacOS libunwind does for framed and frameless stepping.

arm64 can have frames with the same SP (but different IPs). Increment SP for this condition so createdump's unwind
loop doesn't break out on the "SP not increasing" check and the frames are added to the thread frame list in the
correct order.

Add getting the unwind info for tail called functions like this:

__ZL14PROCEndProcessPvji:
   36630:       f6 57 bd a9     stp     x22, x21, [sp, #-48]!
   36634:       f4 4f 01 a9     stp     x20, x19, [sp, #16]
   36638:       fd 7b 02 a9     stp     x29, x30, [sp, dotnet#32]
   3663c:       fd 83 00 91     add     x29, sp, dotnet#32
...
   367ac:       e9 01 80 52     mov     w9, #15
   367b0:       7f 3e 02 71     cmp     w19, dotnet#143
   367b4:       20 01 88 1a     csel    w0, w9, w8, eq
   367b8:       2e 00 00 94     bl      _PROCAbort
_TerminateProcess:
-> 367bc:       22 00 80 52     mov     w2, #1
   367c0:       9c ff ff 17     b       __ZL14PROCEndProcessPvji

The IP (367bc) returns the (incorrect) frameless encoding with nothing on the stack (uses an incorrect LR to unwind). To fix this
get the unwind info for PC -1 which points to PROCEndProcess with the correct unwind info. This matches how lldb unwinds this frame.

Always address module segment to IP lookup list instead of checking the module regions.

Strip pointer authentication bits on PC/LR.
radical pushed a commit that referenced this pull request Feb 7, 2022
* Fix the MacOS remote unwinder for VS4Mac

The wrong module was being passed to the remote unwinder because the load bias for shared modules
was being calculated incorrectly.

Issue: dotnet#63309

* Fix native frame unwind in syscall on arm64 for VS4Mac crash report

From PR in main: dotnet#63598

Add arm64 version of StepWithCompactNoEncoding for syscall leaf node wrappers that have compact encoding of 0.

Fix ReadCompactEncodingRegister so it actually decrements the addr.

Change StepWithCompactEncodingArm64 to match what MacOS libunwind does for framed and frameless stepping.

arm64 can have frames with the same SP (but different IPs). Increment SP for this condition so createdump's unwind
loop doesn't break out on the "SP not increasing" check and the frames are added to the thread frame list in the
correct order.

Add getting the unwind info for tail called functions like this:

__ZL14PROCEndProcessPvji:
   36630:       f6 57 bd a9     stp     x22, x21, [sp, #-48]!
   36634:       f4 4f 01 a9     stp     x20, x19, [sp, #16]
   36638:       fd 7b 02 a9     stp     x29, x30, [sp, dotnet#32]
   3663c:       fd 83 00 91     add     x29, sp, dotnet#32
...
   367ac:       e9 01 80 52     mov     w9, #15
   367b0:       7f 3e 02 71     cmp     w19, dotnet#143
   367b4:       20 01 88 1a     csel    w0, w9, w8, eq
   367b8:       2e 00 00 94     bl      _PROCAbort
_TerminateProcess:
-> 367bc:       22 00 80 52     mov     w2, #1
   367c0:       9c ff ff 17     b       __ZL14PROCEndProcessPvji

The IP (367bc) returns the (incorrect) frameless encoding with nothing on the stack (uses an incorrect LR to unwind). To fix this
get the unwind info for PC -1 which points to PROCEndProcess with the correct unwind info. This matches how lldb unwinds this frame.

Always address module segment to IP lookup list instead of checking the module regions.

Strip pointer authentication bits on PC/LR.
radical pushed a commit that referenced this pull request May 24, 2022
This adds support for EnC on arm64. A couple of notes on the
implementation compared to x64:
- On x64 we get the fixed stack size from unwind info. However, for the
  frames we set up on arm64 for EnC it is not possible to extract the
  frame size from there because their prologs generally look like

  stp fp, lr, [sp,#-16]!
  mov fp, sp
  sub sp, sp, dotnet#144

  with unwind codes like the following:

  set_fp; mov fp, sp

  save_fplr_x #1 (0x01); tp fp, lr, [sp, #-16]!

  As can be seen, it is not possible to get the fixed stack size from
  unwind info in this case. Instead we pass it through the GC info that
  already has a section for EnC data.

- On arm64 the JIT is required to place the PSPSym at the same offset
  from caller-SP for both the main function and for funclets. Due to
  this we try to allocate the PSPSym as early as possible in the main
  function and we must take some care in funclets.  However, this
  conflicts with the EnC frame header that the JIT uses to place values
  that must be preserved on EnC transitions. This is currently
  callee-saved registers and the MonitorAcquired boolean.

  Before this change we were allocating PSPSym above (before) the
  monitor acquired boolean, but we now have to allocate MonitorAcquired
  first, particularly because the size of the preserved header cannot
  change on EnC transitions, while the PSPSym can disappear or appear.
  This changes frame allocation slightly for synchronized functions.
radical pushed a commit that referenced this pull request Jun 2, 2022
These helpers are used to report names of things in warnings. The functional changes are:
* For method parameters, use the parameter name if available (and only if not fallback to the #1 notation)
* For property accessor methods, use the C# naming scheme, so for example Type.Property.get instead of Type.get_Property.

Both of these changes are in preparation to bring NativeAOT closer in behavior to ILLink and the trim analyzers.

For this I moved some of the helpers to the common shared code.

Some unrelated code cleanup as well.

Co-authored-by: Michal Strehovský <MichalStrehovsky@users.noreply.github.com>
radical pushed a commit that referenced this pull request Jun 23, 2022
* Initial implementation for contract customization

fix build errors

Move converter rooting to DefaultJsonTypeInfoResolver so that it can be used standalone

Fix ConfigurationList.IsReadOnly

Minor refactorings (#1)

* Makes the following changes:

* Move singleton initialization for DefaultTypeInfoResolver behind a static property.
* Consolidate JsonSerializerContext & IJsonTypeInfoResolver values to a single field.
* Move reflection fallback logic away from JsonSerializerContext and into JsonSerializerOptions

* Update src/libraries/System.Text.Json/src/System/Text/Json/Serialization/JsonSerializerOptions.cs

* remove testing of removed field

Simplify the JsonTypeInfo.CreateObject implemenetation (#2)

* Simplify the JsonTypeInfo.CreateObject implemenetation

* Update src/libraries/System.Text.Json/src/System/Text/Json/Serialization/Metadata/JsonTypeInfoOfT.cs

* Update src/libraries/System.Text.Json/src/System/Text/Json/Serialization/Metadata/JsonTypeInfoOfT.cs

Co-authored-by: Krzysztof Wicher <mordotymoja@gmail.com>

Co-authored-by: Krzysztof Wicher <mordotymoja@gmail.com>

Tests and fixes for JsonTypeInfoKind.None

TypeInfo type mismatch tests

Allow setting NumberHandling on JsonTypeInfoKind.None

test resolver returning wrong type of options

JsonTypeInfo/JsonPropertyInfo mutability tests

rename test file

Move default converter rooting responsibility behind DefaultJsonTypeInfoResolver (#3)

* Move default converter rooting responsibility behind DefaultJsonTypeInfoResolver

* address feedback

Add simple test for using JsonTypeInfo<T> with APIs directly taking it

fix and tests for untyped/typed CreateObject

uncomment test cases, remove todo

More tests and tiny fixes

Add a JsonTypeInfoResolver.Combine test for JsonSerializerContext (#4)

* Fix JsonTypeInfoResolver.Combine for JsonSerializerContext

* Break up failing test

Fix simple scenarios for combining contexts (#6)

* Fix simple scenarios for combining contexts

* feedback

JsonSerializerContext combine test with different camel casing

Remove unneeded virtual calls & branching when accessing Get & Set delegates (#7)

JsonPropertyInfo tests everything minus ShouldSerialize & NumberHandling

Update src/libraries/System.Text.Json/src/System/Text/Json/Serialization/JsonConverterOfT.cs

Update src/libraries/System.Text.Json/src/System/Text/Json/Serialization/JsonConverterOfT.cs

throw InvalidOperationException rather than ArgumentNullException for source gen when PropertyInfo.Name is assigned through JsonPropertyInfoValues

tests for duplicated property names and JsonPropertyInfo.NumberHandling

Add tests for NumberHandling and failing tests for ShouldSerialize

disable the failing test and add extra checks

disable remainder of the failing ShouldSerialize tests, fix working one

Fix ShouldSerialize and IgnoreCondition interop

Add failing tests for CreateObject + parametrized constructors

Fix CreateObject support for JsonConstructor types (#10)

* Fix CreateObject support for JsonConstructor types

* address feedback

Make contexts more combinator friendly (#9)

* Make contexts more combinator friendly

* remove converter cache

* redesign test to account for JsonConstructorAttribute

* Combine unit tests

* address feedback

* Add acceptance tests for DataContract attributes & Specified pattern (#11)

* Add private field serialization acceptance test (#13)

* tests, PR feedback (#14)

* PR feedback and extra tests

* Shorten class name, remove incorrect check (not true for polimorphic cases)

* Make parameter matching for custom properties map property Name with parameter (#16)

* Test static initialization with JsonTypeInfo (#17)

* Fix test failures and proper fix this time (#18)

* Fix test failures and proper fix this time

* reinstate ActiveIssueAttribute

* PR feedback and adjust couple of tests which don't set TypeInfoResolver

* fix IAsyncEnumerable tests

* Lock JsonSerializerOptions in JsonTypeInfo.EnsureConfigured()

Co-authored-by: Eirik Tsarpalis <eirik.tsarpalis@gmail.com>

Co-authored-by: Eirik Tsarpalis <eirik.tsarpalis@gmail.com>
radical pushed a commit that referenced this pull request Jul 1, 2022
E.g.,

Update LSRA "Allocating Registers" table description.

Dump nodes added during resolution, e.g.:
```
   BB29 bottom (BB08->BB08): move V25 from STK to rdi (Critical)
N001 (  1,  1) [001174] ----------z                 t1174 =    LCL_VAR   int    V25 cse4          rdi REG rdi
```

Dump more data in the LSRA block sequence data:
```
-BB03( 16   )
-BB04(  4   )
+BB03 ( 16   ) critical-in critical-out
+BB04 (  4   ) critical-out
```

When dumping various flow bitvectors, annotate the bitvectors better:
```
-BB25 in gen out
-0000000000000000
-0000000000000003 CSE #1.c
-0000000000000003 CSE #1.c
+BB25
+ in: 0000000000000000
+gen: 0000000000000003 CSE #1.c
+out: 0000000000000003 CSE #1.c
```

Dump hoisting bitvectors using the sorting number:
```
-  USEDEF  (5)={V04 V00 V01 V02 V03}
+  USEDEF  (5)={V00 V01 V02 V03 V04}
```

Also, fix various typos and formatting.
radical pushed a commit that referenced this pull request Jul 7, 2022
radical pushed a commit that referenced this pull request Aug 25, 2022
* WIP: add gRPC tests

* Fix AOT and trimming

* WIP

* Implement IncludeNetworkSecurityConfig

* Use IncludeNetworkSecurityConfig

* Fix gRPC test

* Avoid git checkout

* Remove unnecessary code

* WIP: start working on CI configuration

* Remove WinHttpHandler

* Fix problem with SSL

* Change server host

* Setup CI (#1)

* Get Docker container building & exported via test build

* Changes

* Add missing pfx certificate

* changes

* cleanup

Co-authored-by: Simon Rozsival <simon@rozsival.com>

* Use tls

* Update yml

* Revert changes to the mono Android sample app

* Bump android image version

* Bump image version

* Enable TLS

* Remove hardcoded package versions

* Update package versions

* Update package versions

* Rename pipeline

* Move interop tests website dependencies versions to Versions.props

* Add cred scan supression for the interop test server private key

* Fix licenses

* Remove dependencies

* Fix path to Versions.props

* Remove unnecessary dependency version

* Fix building docker image

* Change pfx password

Co-authored-by: Jo Shields <directhex@apebox.org>
radical pushed a commit that referenced this pull request Jan 3, 2023
* switch to managed thread ID in Lock

* fattening the lock

* __declspec(selectany)

* few tweaks

* fairness

* more room for thread ids

* remove CurrentNativeThreadId

* couple fixes

* fix win-arm64 build

* win-arm64 build , another try

* Apply suggestions from code review

Co-authored-by: Jan Kotas <jkotas@microsoft.com>

* fix after renaming

* do not report successful spin if thread has waited

* keep extern and undo mangling of tls_CurrentThread in asm

* use SyncTable indexer in less perf-sensitive places.

* GetNewHashCode just delegate to shared random

* Apply suggestions from code review

Co-authored-by: Jan Kotas <jkotas@microsoft.com>

* unchecked const conversion

* some refactoring comments and typos

* min number of spins in the backoff

* moved CurrentManagedThreadIdUnchecked to ManagedThreadId

* Use `-1` to report success and allow using  element #1 in the SyncTable

* use threadstatic for managed thread ID

* check before calling RhGetProcessCpuCount

* use 0 as default thread ID

Co-authored-by: Jan Kotas <jkotas@microsoft.com>
radical pushed a commit that referenced this pull request Jun 9, 2023
…tnet#87189)

This fixes a startup crash on Big Sur:

> error: * Assertion at /Users/runner/work/1/s/src/mono/mono/utils/mono-hwcap-arm64.c:35, condition `res == 0' not met

Because sysctl can't find some of these options:

    $ sysctl hw.optional.armv8_crc32
    hw.optional.armv8_crc32: 1
    $ sysctl hw.optional.arm.FEAT_RDM
    sysctl: unknown oid 'hw.optional.arm.FEAT_RDM'
    $ sysctl hw.optional.arm.FEAT_DotProd
    sysctl: unknown oid 'hw.optional.arm.FEAT_DotProd'
    $ sysctl hw.optional.arm.FEAT_SHA1
    sysctl: unknown oid 'hw.optional.arm.FEAT_SHA1'
    $ sysctl hw.optional.arm.FEAT_SHA256
    sysctl: unknown oid 'hw.optional.arm.FEAT_SHA256'
    $ sysctl hw.optional.arm.FEAT_AES
    sysctl: unknown oid 'hw.optional.arm.FEAT_AES'

Full stack trace:

* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 2.1
  * frame #0: 0x0000010ef37560 libmonosgen-2.0.dylib`monoeg_assertion_message
    frame #1: 0x0000010ef375cc libmonosgen-2.0.dylib`mono_assertion_message + 32
    frame #2: 0x0000010ef40d6c libmonosgen-2.0.dylib`mono_hwcap_arch_init + 544
    frame #3: 0x0000010ef54bd8 libmonosgen-2.0.dylib`mono_hwcap_init + 72
    frame #4: 0x0000010ee14dc0 libmonosgen-2.0.dylib`parse_optimizations + 52
    frame #5: 0x0000010edbed48 libmonosgen-2.0.dylib`mono_init
    frame #6: 0x0000010ee18968 libmonosgen-2.0.dylib`mono_jit_init_version
    frame #7: 0x0000010f48a300 libxamarin-dotnet-debug.dylib`xamarin_bridge_initialize + 216
    frame #8: 0x0000010f4900a4 libxamarin-dotnet-debug.dylib`xamarin_main + 376
radical pushed a commit that referenced this pull request Nov 29, 2023
Fixes dotnet#95367.

Relevant part of the JitDump:

```
Using `if true` assertions from pred BB02
Assertions in: #1
fgMorphTree BB04, STMT00021 (before)
               [000070] DA---------                         *  STORE_LCL_VAR ubyte  V10 tmp9
               [000057] -----------                         \--*  CAST      int <- ubyte <- int
               [000006] -----------                            \--*  EQ        int
               [000004] -----------                               +--*  LCL_VAR   ref    V02 tmp1          (last use)
               [000055] H----------                               \--*  CNS_INT(h) ref     'Frozen EmptyPartition`1<Int32> object'

Assertion prop for index #1 in BB04:
               [000006] -----------                         *  EQ        int
GenTreeNode creates assertion:
               [000070] DA---+-----                         *  STORE_LCL_VAR ubyte  V10 tmp9
In BB04 New Local Constant Assertion: V10 == [0000000000000001], index = #2

fgMorphTree BB04, STMT00021 (after)
               [000070] DA---+-----                         *  STORE_LCL_VAR ubyte  V10 tmp9
               [000055] H----+-----                         \--*  CNS_INT(h) int
```

The JitDump is unfinished because the compiler crashes when trying to dump the last line. Clearly, the `CNS_INT` is no longer a handle at that point because we just bashed it to a constant 1.
radical pushed a commit that referenced this pull request May 22, 2024
CodeQL flagged various places where we're dereferencing pointers that could be NULL, this PR systematically cleans some of them up via g_assert.
* g_assert result of g_build_path calls
* Allocation failure handling
* mono_class_inflate_generic_class_checked can return NULL
radical pushed a commit that referenced this pull request May 22, 2024
…#102133)

This generalizes the indir reordering optimization (that currently only
triggers for loads) to kick in for GT_STOREIND nodes.

The main complication with doing this is the fact that the data node of
the second indirection needs its own reordering with the previous
indirection. The existing logic works by reordering all nodes between
the first and second indirection that are unrelated to the second
indirection's computation to happen after it. Once that is done we know
that there are no uses of the first indirection's result between it and
the second indirection, so after doing the necessary interference checks
we can safely move the previous indirection to happen after the data
node of the second indirection.

Example:
```csharp
class Body { public double x, y, z, vx, vy, vz, mass; }

static void Advance(double dt, Body[] bodies)
{
    foreach (Body b in bodies)
    {
        b.x += dt * b.vx;
        b.y += dt * b.vy;
        b.z += dt * b.vz;
    }
}
```

Diff:
```diff
@@ -1,18 +1,17 @@
-G_M55007_IG04:  ;; offset=0x001C
+G_M55007_IG04:  ;; offset=0x0020
             ldr     x3, [x0, w1, UXTW #3]
             ldp     d16, d17, [x3, #0x08]
             ldp     d18, d19, [x3, #0x20]
             fmul    d18, d0, d18
             fadd    d16, d16, d18
-            str     d16, [x3, #0x08]
-            fmul    d16, d0, d19
-            fadd    d16, d17, d16
-            str     d16, [x3, #0x10]
+            fmul    d18, d0, d19
+            fadd    d17, d17, d18
+            stp     d16, d17, [x3, #0x08]
             ldr     d16, [x3, #0x18]
             ldr     d17, [x3, #0x30]
             fmul    d17, d0, d17
             fadd    d16, d16, d17
             str     d16, [x3, #0x18]
             add     w1, w1, #1
             cmp     w2, w1
             bgt     G_M55007_IG04
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.