locked
CLR Profiling API - Detecting a field access RRS feed

  • Question

  • Is there a concrete way to find out if a specific field of a specific object is being accessed? It looks it would be possible to look at the IL and see for LdFld opcodes. Is that good enough? Are there other ways an objects field maybe accessed?
    Tuesday, January 21, 2014 6:37 PM

Answers

  • I don't really understand what you are saying. You have a profiler and you're modifying IL code on the fly. OK, but what has this to do with field accesses?

    Thursday, January 23, 2014 10:33 PM

All replies

  • LdFld is the most common way to access a field. There's also LdFldA which is used in cases like foobar(ref fieldX) and when this is used it may be more difficult to track down the actual field access. And there's also a possibility that fields are accessed via pointers/PInvoke/internal runtime calls.

    Wednesday, January 22, 2014 7:37 AM
  • Hi Mahima,

    >Is there a concrete way to find out if a specific field of a specific object is being accessed?

    I doubt you cannot do this. Because I have not seen this feature from the feature list in the following link. http://msdn.microsoft.com/en-us/library/bb384493(v=vs.110).aspx#support. Or am I missing something?

    You cannot implement the CLR profiling APIs in managed code. David Broman, the developer of CLR profiling APIs, has said that “you need to write your profiler in c++. The profiler is called by the runtime at very delicate points during execution of the profiled application, and it is often extremely unsafe to be running managed code at those points”. Please refer to the following link to see his blog. http://blogs.msdn.com/b/davbr/.

    Hope useful to you.

    Regards,


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Wednesday, January 22, 2014 8:28 AM
  • I'm mostly interested on fields being accessed by managed code.

    How does one access a field from a PInvoke or a pointer? And then why would one do that? I'm just trying to picture some code and having a hard time.

    LdFldA is now the tricky one. I'm trying to think if there would be a way to even track it down? Do you have any ideas?

    LdFld seems to always put the object pointer, so I guess I can associate a field access to a particular object.

    Any additional ideas are appreciated.

    Wednesday, January 22, 2014 6:08 PM
  • "How does one access a field from a PInvoke or a pointer? And then why would one do that? I'm just trying to picture some code and having a hard time."

    Well, I'm just saying that it is possible. I don't know if this is something you need to be concerned about, it depends on the reason you're trying to track down field accesses.

    "LdFldA is now the tricky one. I'm trying to think if there would be a way to even track it down?"

    Well, finding the LdFldA itself is no different from finding LdFld. But finding where the field is actually accessed via the pointer generated by LdFldA is another story. It requires a bit of data flow analysis and it has do be done accross functions, not exactly trivial.

    Wednesday, January 22, 2014 9:54 PM
  • Thanks.

    I was wondering that if I end up calling managed code from the modified IL, and I access a field from that modified IL .. I will get a profiler callback for that also right?

    So I basically need to detect "my profiler managed code" and not JIT that with the IL that causes a callout to my managed code?

    Thursday, January 23, 2014 10:09 PM
  • I don't really understand what you are saying. You have a profiler and you're modifying IL code on the fly. OK, but what has this to do with field accesses?

    Thursday, January 23, 2014 10:33 PM