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

Share managed EventSource/EventPipe implementation between CoreCLR and Mono. #33425

Merged

Conversation

lateralusX
Copy link
Member

First set of changes needed in order to start sharing managed EventSource/EventPipe code between CoreCLR and Mono runtime. Shareable code has been moved into S.P.C library project and split into runtime specific source files when needed, kept within each runtime specific S.P.C project files.

Mono runtime has been extended with a set of icalls needed by EventPipeInternal, just to make sure EventPipe can be initialized, current Mono runtime implementation returns dummy values.

Current change also enables ETW provider support on Mono Windows runtime.

NOTE, this is just initial changes needed in order to share managed EventSource/EventPipe code between runtimes. Future changes will incrementally add EventPipe native code into Mono runtime.

@lateralusX lateralusX changed the title Share managed EventSource/EventPipe implementation between CoreCLR and Mono. WIP: Share managed EventSource/EventPipe implementation between CoreCLR and Mono. Mar 10, 2020
@lateralusX
Copy link
Member Author

EventPipeEventDispatcher is depending on Interop.Kernel32.SetEvent PAL, currently not available on Mono none Windows platforms, causing build errors. Will look into alternatives, but most likely move logic down into EveptPipeInternal where we can do different implementations.

Couple of build errors due to switching over to define instead of include/exclude for a couple of source files, will adjust those to be included/excluded based on features.

@lateralusX lateralusX changed the title WIP: Share managed EventSource/EventPipe implementation between CoreCLR and Mono. Share managed EventSource/EventPipe implementation between CoreCLR and Mono. Mar 10, 2020
@lateralusX lateralusX force-pushed the lateralusX/tracing-support-monovm branch from 8cc2cc4 to 3bd00f3 Compare March 10, 2020 22:09
Copy link
Member

@lambdageek lambdageek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a few nits, but mostly the Mono runtime bits lgtm

src/mono/mono/metadata/icall.c Outdated Show resolved Hide resolved
src/mono/mono/metadata/icall.c Show resolved Hide resolved
Copy link
Member

@noahfalk noahfalk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like a fine start to me

…d Mono.

First changes needed in order to start sharing managed EventSource/EventPipe
code between CoreCLR and Mono runtime. Sharable code has been moved into
S.P.C library project and split into runtime specific source files when
needed, kept within each runtime specific S.P.C project files.

Mono runtime has been extended with a set of icalls needed by
EventPipeInternal, just to make sure EventPipe can be initialized,
current Mono runtime implementation returns dummy values.

Current change also enables ETW provider support on Mono Windows runtime.

NOTE, this is just initial changes needed in order to share managed
EventSource/EventPipe code between runtimes. Future changes will incrementally
add EventPipe native code into Mono runtime.
@lateralusX lateralusX force-pushed the lateralusX/tracing-support-monovm branch from 3b25184 to 928542f Compare March 12, 2020 09:13
@lateralusX lateralusX merged commit 70bfd2a into dotnet:master Mar 12, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants