-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Add System.Diagnostics.StackFrame.GetMethodFromNativeIP API for VS4Mac #61289
Conversation
Tagging subscribers to this area: @tommcdon Issue DetailsVS4Mac needs a way to symbolize managed IPs when rethrowing a native NSException from Objective C++. This is a short term API needed for the next 6.0 service release discoverable only through reflection. Issue: #61186
|
src/coreclr/System.Private.CoreLib/src/System/Diagnostics/StackFrame.CoreCLR.cs
Outdated
Show resolved
Hide resolved
… to GetMethodFromNativeIP.
src/mono/System.Private.CoreLib/src/System/Diagnostics/StackFrame.Mono.cs
Outdated
Show resolved
Hide resolved
mono apparently has If VS4Mac's debugger also uses |
There are design options for the crash diagnostic: managed APIs, unmanaged APIs, out-of-proc APIs, ... . We believe that adding this internal managed API is the best first step to enable VS Mac to get crash dump diagnostic. We plan to do some more refactoring on top of this and expose this functionality as a proper public managed API. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few comment suggestions, but functionally LGTM : )
Thanks Mike!
src/coreclr/System.Private.CoreLib/src/System/Diagnostics/StackFrame.CoreCLR.cs
Outdated
Show resolved
Hide resolved
/// </summary> | ||
/// <param name="ip">code address</param> | ||
/// <returns>MethodBase instance for the method or null if IP not found</returns> | ||
internal static MethodBase? GetMethodFromNativeIP(IntPtr ip) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably add a comment right here saying that the implementation of this method has known race conditions for unloadable code + MethodBase isn't a good design choice for working with NativeAOT, therefore don't make it public in the future without considering those issues. Reduces the chance we forget the history when we need a public API later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or even better - create issue that tracks adding the public API and link it from here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a TODO describing most of this here: https://github.com/mikem8361/runtime/blob/b3a9a6086dcef769b82a5750489738254b6aee80/src/coreclr/vm/debugdebugger.cpp#L788
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is that good enough?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did add a comment to the method's header.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do think having the message that you added right here in the header is valuable. When people convert a private API to public nothing enforces that they will look at implementation code in a separate file. The comment you added calls out the race condition but doesn't mention the design issue for using MethodBase in NativeAOT. As @jkotas suggested filing an issue and linking to that is an improvement over my original suggestion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to use issue #61186 to detail these limitations and to propose the new 7.0 API.
VS4Mac needs a way to symbolize managed IPs when rethrowing a native NSException from Objective C++. This is a short term API needed for the next 6.0 service release discoverable only through reflection.
Issue: #61186