[dotnet-trace] Add option to stop tracing on trigger

[steveisok]

In order to better support tracing in mobile scenarios, we would like the ability to stop a trace based on a trigger. For example, we are using dotnet-trace to profile an Android application at startup. It would be helpful if we could stop a trace based on a common method name.

An example:

dotnet-trace /trigger:MethodName=<method-name:>

[steveisok]

@tommcdon Can you add the enhancement label? I don't appear to be able to.

[tommcdon]

@tommcdon Can you add the enhancement label? I don't appear to be able to.

Added

[samsp-msft]

Q: Should there be an API in System.Diagnostics for the app to be able to control tracing. GoLang has you call profiling api's explicitly as part of the app code to start and stop tracing.

We could have an API to:

• Start tracing if a tracer is attached, and block if none is attached
• Start tracing and not block
• Stop tracing
• Write a sign-post event into the trace. When debugging an issue, or trying to understand performance, it can be useful to be able to write simple events that can then act as signposts when doing analysis, without having to go to the effort of declaring a custom event, and making sure its collected. It would be the tracing equivalent of System.DIagnostics.Debug.WriteLine.

[steveisok]

/cc @lateralusX

[lateralusX]

First step will be to have similar support as added to dotnet-monitor around stop trigger. Original idea when implementing that was to share/port that code into dotnet-trace as well so we end up with similar functionality. Alternative is to do something along perfviews abilities to start/stop trace based on custom event triggers, but since we already implemented something similar in dotnet-monitor, I believe it make more sense to align to that implementation (or having multiple options).

One challenge with this implementation is to keep event streaming running with least amount of impact (since a degrade in read performance could lead to dropped events), side effect of this is that once the trigger has been detected and session have been stopped, .nettrace file will still need to include rundown events, so there will always be an unknow number of events past stop trigger that might end up in nettrace file. This could be an issue if the nettrace file will be used together with tools like dotnet-pgo, since that might lead to more methods getting AOT:ed than anticipated. In order to mitigate that scenario + adding support for a bunch of new scenarios, dotnet/runtime#89853 was implemented giving the user ability to use the same method as used as stop trigger as the end filter passed to dotnet-pgo. The new filter capabilities in dotnet-pgo together with ability to merge mibc file and ability in Mono cross compilers to accept multiple mibc files opens up ability to make detailed control on what methods that will an up AOT:ed in the profiled AOT use case.

If we are going to utilize the same capabilities as dotnet-monitor in dotnet-traces stop trigger implementation, the following PR reference the implementation of stop trigger in dotnet-monitor, dotnet/dotnet-monitor#2557.