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

VS4Mac needs a runtime API to symbolize managed IPs #61186

Closed
mikem8361 opened this issue Nov 3, 2021 · 7 comments
Closed

VS4Mac needs a runtime API to symbolize managed IPs #61186

mikem8361 opened this issue Nov 3, 2021 · 7 comments
Assignees
Labels
area-Diagnostics-coreclr enhancement Product code improvement that does NOT require public API changes/additions
Milestone

Comments

@mikem8361
Copy link
Member

mikem8361 commented Nov 3, 2021

Background and motivation

VS4Mac needs a way to symbolize managed IPs when rethrowing a native NSException from Objective C++. They do the symbolizing in the telemetry upload on the unhandled NSException crash. They don't currently build a StackTrace/StackFrames when the managed NSException wrapper is thrown so all they need currently is a way to convert a IP address of a managed method into a full method name string.

This is a short term API needed for the next 6.0 service release discoverable only through reflection.

API Proposal

namespace  System.Diagnostics
{
    public class StackFrame
    {
         /// <summary>
        /// Returns the method info instance for the managed code IP address.
        /// </summary>
        /// <param name="ip">code address</param>
        /// <returns>MethodBase instance or null if IP not found</returns>
        internal static MethodBase? GetMethodFromNativeIP(IntPtr ip);
    }
}

API Usage

Type stackFrameType = typeof(System.Diagnostics.StackFrame);
MethodInfo? getMethodFromNativeIP = stackFrameType.GetMethod("GetMethodFromNativeIP", BindingFlags.NonPublic | BindingFlags.Static);
if (getMethodFromNativeIP is null)
{
    Console.WriteLine("GetMethodFromNativeIP not found");
    return;
}

long ip = 0;
MethodBase? testFunction = getMethodFromNativeIP.Invoke(null, new object[] { new IntPtr(ip) }) as MethodBase;
if (testFunction is null)
{
    Console.WriteLine("Test function not found");
    return;
}

Alternative Designs

For .NET 7.0, we could replace this temporary API with this public one:

public class StackFrame
{
    public static StackFrame? CreateFromNativeIP(IntPtr nativeIP, bool needFileInfo = false); 
}

Risks

The .NET 6.0 API has the following limitations that will need to be addressed:

  1. There is a race condition for dynamic and collectable methods between when the MethodDesc is found and where it is wrapped in the MethodBase.
  2. MethodBase isn't a good design choice for working with NativeAOT.
@mikem8361 mikem8361 added this to the 6.0.x milestone Nov 3, 2021
@mikem8361 mikem8361 self-assigned this Nov 3, 2021
@dotnet-issue-labeler
Copy link

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

@dotnet-issue-labeler dotnet-issue-labeler bot added the untriaged New issue has not been triaged by the area owner label Nov 3, 2021
@mikem8361 mikem8361 added area-Diagnostics-coreclr and removed untriaged New issue has not been triaged by the area owner labels Nov 3, 2021
@ghost
Copy link

ghost commented Nov 3, 2021

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Issue Details

Background and motivation

VS4Mac needs a way to symbolize managed IPs when rethrowing the NSException from Objective C++.

API Proposal

namespace  System.Runtime.CompilerServices.
{
    public static partial class RuntimeHelpers
    {
         /// <summary>
        /// Returns the method info instance for the managed code IP address.
        /// </summary>
        /// <param name="ip">code address</param>
        /// <returns>MethodInfo instance or null if IP not found</returns>
        internal static MethodInfo? GetMethodInfoFromIP(IntPtr ip);
    }
}

API Usage

TBD

Alternative Designs

No response

Risks

No response

Author: mikem8361
Assignees: mikem8361
Labels:

area-Diagnostics-coreclr

Milestone: 6.0.x

@jkotas
Copy link
Member

jkotas commented Nov 4, 2021

Do you mean for this to become a public API in .NET 7?

I think it should be under System.Diagnostics namespace somewhere. Maybe a static factory method on StackFrame?

public class StackFrame
{
    public static StackFrame? CreateFromNativeIP(IntPtr nativeIP, bool needFileInfo = false); 
}

StackFrame will give you access to all other diagnostic information for the given IP: relative offset within the method, optional filenames, etc.

@jkotas
Copy link
Member

jkotas commented Nov 4, 2021

Also, why is not System.Diagnostics.StackTrace enough? Note that there is StackTrace constructor that takes Exception.

@jkotas
Copy link
Member

jkotas commented Nov 4, 2021

There is an existing API StackFrameExtensions.GetNativeIP. So this one should be called GetMethodInfoFromNativeIP to make the naming consistent.

@mikem8361
Copy link
Member Author

I included you on a thread that should have more background/context. This issue is a WIP and isn't fleshed out.

mikem8361 added a commit to mikem8361/runtime that referenced this issue Nov 6, 2021
mikem8361 added a commit to mikem8361/runtime that referenced this issue Nov 7, 2021
…S4Mac

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: dotnet#61186
mikem8361 added a commit that referenced this issue Nov 9, 2021
#61289)

* Add System.Diagnostics.StackFrame.GetMethodInfoFromNativeIP API for VS4Mac

Issue: #61186
Anipik pushed a commit that referenced this issue Nov 10, 2021
…tiveIP API for VS4Mac (#61298)

* Add System.Diagnostics.StackFrame.GetMethodInfoFromNativeIP API for VS4Mac

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

* Code review feedback

* Remove unneccesary blank line
@mikem8361 mikem8361 modified the milestones: 6.0.x, 7.0.0 Nov 11, 2021
@mikem8361 mikem8361 added feature-request enhancement Product code improvement that does NOT require public API changes/additions and removed feature-request labels Jan 24, 2022
@mikem8361 mikem8361 modified the milestones: 7.0.0, 8.0.0 Jun 16, 2022
@tommcdon
Copy link
Member

No active requests for this feature, closing

@ghost ghost locked as resolved and limited conversation to collaborators Jun 17, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-Diagnostics-coreclr enhancement Product code improvement that does NOT require public API changes/additions
Projects
None yet
Development

No branches or pull requests

3 participants