-
Notifications
You must be signed in to change notification settings - Fork 48
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 support for user created buffers for raw profiler hooks #451
Conversation
Do we need to do something similar for SetILInstrumentedCodeMap? I.E. if there is no CMethodInfoInstance, and user buffers are enabled, then just directly set the code map? Refers to: src/InstrumentationEngine/CorProfilerInfoWrapper.cpp:434 in c259b82. [](commit_id = c259b82, deletion_comment = False) |
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.
🕐
Please remember to update the changelog.md file In reply to: 951147810 |
I don't think we need to set these for brand new methods, since there's no mapping from old il to new il. But you are correct, we will fail this call since we won't find the existing method. |
Yeah, I don't know what the CLR will do in this case. Technically, I don't think that you are limited to setting the IL for a method at module load only if it is a brand new method. I can imagine a world where someone reads the IL from disk, creates a new method, and sets the code map before the first jit... but that is probably not a common use case. In reply to: 952157974 |
c259b82
to
69a533d
Compare
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
@@ -13,6 +13,8 @@ MicrosoftInstrumentationEngine::CCorMethodMalloc::CCorMethodMalloc() : m_cbBuffe | |||
|
|||
PVOID MicrosoftInstrumentationEngine::CCorMethodMalloc::Alloc(_In_ ULONG cb) | |||
{ | |||
//TODO Any consecutive calls to Alloc will destroy the previous buffer. |
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.
Consider failing subsequent calls or leaking the buffer
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.
leak + log
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.
It looks like this is the default code flow; we don't have independent cleanup for this buffer, we rely on subsequent AllocCalls or ref counting to cleanup. I will leave this as is for now.
if (moduleId == m_testModule) | ||
{ | ||
if (m_firstJit) | ||
{ |
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.
Extra tests:
- Double Alloc
- Order between IM and Raw maintained
- Order inversion with both modifying the method.
- Make sure repeat calls to SetILFunctionBody behave as expected.
4185b6c
to
ef32601
Compare
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
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.
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
Adds support for 3 different scenarios in raw profiler hooks:
TODO: