refactoring from PR 369 #1
Comments
sandreenko
pushed a commit
that referenced
this issue
Feb 5, 2020
Fix unhandled exception line number issues There are a few paths to get the place (DebugStackTrace::DebugStackTraceElement::InitPass2) where the offset/ip needs an adjustment: 1) The System.Diagnostics.StackTrace constructors that take an exception object. The stack trace in the exception object is used (from the _stackTrace field). 2) Processing an unhandled exception for display (ExceptionTracker::ProcessOSExceptionNotification). 3) The System.Diagnostics.StackTrace constructors that don't take an exception object that get the stack trace of the current thread. For cases #1 and #2 the StackTraceInfo/StackTraceElement structs are built when the stack trace for an exception is generated and is put in the private _stackTrace Exception object field. The IP in each StackTraceElement is decremented for hardware exceptions and not for software exceptions because the CrawlFrame isInterrupted/hasFaulted fields are not initialized (always false). This is backwards for h/w exceptions leaf node frames but really can't be changed to be compatible with other code in the runtime and SOS. The fIsLastFrameFromForeignStackTrace BOOL in the StackTraceElement/DebugStackTraceElement structs have been replaced with INT "flags" field defined by the StackTraceElementFlags enum. There is a new flag that is set (STEF_IP_ADJUSTED) if the IP has been already adjusted/decremented. This flag is used to adjust the native offset when it is converted to an IL offset for source/line number lookup in DebugStackTraceElement::InitPass2(). When the stack trace for an exception is rendered to a string (via the GetStackFramesInternal FCALL) the internal GetStackFramesData/DebugStackTraceElement structs are initialized. This new "flags" field is passed from the StackTraceElement to the DebugStackTraceElement struct. For case #3 all this happens in the GetStackFramesInternal FCALL called from the managed constructor building the GetStackFramesData/DebugStackTraceElement structs directly. Fixes issues dotnet#27765 and dotnet#25740. Fix IL offset map search.
sandreenko
pushed a commit
that referenced
this issue
Mar 17, 2020
This adds support in the JIT emitter for Vector Load/Store structure instructions (C3.2.10 - Arm
Architecture Reference Manual):
- LD1 (1-4 registers)
- LD2
- LD3
- LD4
- LD1R
- LD2R
- LD3R
- LD4R
- ST1 (1-4 registers)
- ST2
- ST3
- ST4
in the following addressing modes:
- Base register only
- Post-indexed by a 64-bit register
- Post-indexed by an immediate, equal to the number of bytes transferred
Also adds support in JitDump for printing of
* A SIMD vector register list.
For example, ld1 {v5.16b, v6.16b, v7.16b, v8.16b}, [x9]
* A SIMD vector element list.
For example, st1 {v0.b}[3], [x1],#1
sandreenko
pushed a commit
that referenced
this issue
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 : dotnet#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 : dotnet#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 : dotnet#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) ```
sandreenko
pushed a commit
that referenced
this issue
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
sandreenko
pushed a commit
that referenced
this issue
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
sandreenko
pushed a commit
that referenced
this issue
Jan 23, 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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
No description provided.
The text was updated successfully, but these errors were encountered: