none
Is there any solution to visualise a class that use an opaque pointer? RRS feed

  • Question

  • Hello,

    Currently, I’m working with Natvis to setup the visualization of our C++ types inside the debugger. Our library uses opaque pointers to hide the implementation. A drawback is that is difficult to write an expression in the Natvis file. We need to hide the implementation to our users. But, we need to provide them some debug facilities. Almost all our types implement a toString() function that represents itself by a string. Is there a way to call this kind of function from the Natvis file?

    I tried few approaches, but none of them worked.

    First, I tried to call function from the Natvis file. As I understand, only intrinsic function can be called and the definition of this kind of function is reserved to the compiler. So we are not able to define our intrinsic function.

    Then, I tried to create an EEAddIn to call the function  toString() from a specific types. I got an 32/64 bit incompatibility where our library is 64 bit and the addin must be run under the debugger in 32 bit. Also, I figure out that the addin will be hard to deploy where the binary, and all its dependencies, must be located in a specific folder.

    Finally, I found that unlike the Natvis file , we can call function from the debugger, i.e. from the watch windows. I did write a function that returns the result of a toString() function from a reference passed in argument. But the syntax is not user friendly and its look like: “({,,"MyLibrary-0.0.dll"}::toString)(myobject)”.

    Our goal is to provide to our users a basic visualisation of the types defined in our library. Is there any solution to visualise a class that use an opaque pointer? A trick to call the toString() function? Or any other solution?

    Thank you

    Thursday, June 13, 2013 8:23 PM

Answers

  • Hi,

    Since we have researched this exact question pursuant to a support case you have opened, I am sharing some of the replies we got from our internal discussion groups, so that others can benefit from their responses:

    (I used different colors to distinguish different people):

    We added a couple of new addin types in dev11  that are referenced from natvis but are not the old style EE addins. They install on the visual studio side of the remoting boundary and can take control of the view of a type or optionally display UI. Using uint64 and the concord readmemory APIs will avoid any 64 bit mismatches (they must be compiled 32 bit but that doesn't  matter as the read memory APIs can cross bitness)

    Calling a function from the debugger is playing with fire. You are likely to deadlock on cross thread dependencies (even if you don't have any explicit cross thread dependencies, there are shared locks for things like memory allocation). This is why the C++ debugger has no support for implicit funceval.

    Will users have a PDB for some module where the type is defined non-opaquely? If so, you could write a natvis rule which said something like ‘treat HFOO’ as ‘(example.dll!CFoo*)’?

    If users don’t have a PDB that has the true representation of the type, you can obviously play games with pointer offsets. For example, if there is a Unicode string field 12 bytes into the pointer, then something like ‘*(LPCWSTR*)(((BYTE*)this)+12)’. For a better example, look at Platform::Exception in WinRT.natvis.

    You can use explicit field offsets and casting to access the hidden implementation from .natvis. I suppose it would technically qualify as exposing the implementation to the users in a roundabout way, but I don’t think that anyone would assume that a .natvis file defines any kind of contract that can be relied upon.

    Scot


    Developer Support Engineer

    Wednesday, June 19, 2013 6:36 PM

All replies

  • Hi,

    Sorry for that I’m not very clear about this issue.

    So this issue is related to the VS debugger tool, you want to visualizers for native types in debugger windows, am I right?

    If so, as far as I know, you could customize it with .natvis file like the following blog.

    http://blogs.msdn.com/b/mgoldin/archive/2012/06/06/visual-studio-2012-and-debugger-natvis-files-what-can-i-do-with-them.aspx

    If I have misunderstood anything, please make free feel to let me know.

    Best Regards,


    Jack Zhai [MSFT]
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Sunday, June 16, 2013 6:57 AM
    Moderator
  • Hi,

    Since we have researched this exact question pursuant to a support case you have opened, I am sharing some of the replies we got from our internal discussion groups, so that others can benefit from their responses:

    (I used different colors to distinguish different people):

    We added a couple of new addin types in dev11  that are referenced from natvis but are not the old style EE addins. They install on the visual studio side of the remoting boundary and can take control of the view of a type or optionally display UI. Using uint64 and the concord readmemory APIs will avoid any 64 bit mismatches (they must be compiled 32 bit but that doesn't  matter as the read memory APIs can cross bitness)

    Calling a function from the debugger is playing with fire. You are likely to deadlock on cross thread dependencies (even if you don't have any explicit cross thread dependencies, there are shared locks for things like memory allocation). This is why the C++ debugger has no support for implicit funceval.

    Will users have a PDB for some module where the type is defined non-opaquely? If so, you could write a natvis rule which said something like ‘treat HFOO’ as ‘(example.dll!CFoo*)’?

    If users don’t have a PDB that has the true representation of the type, you can obviously play games with pointer offsets. For example, if there is a Unicode string field 12 bytes into the pointer, then something like ‘*(LPCWSTR*)(((BYTE*)this)+12)’. For a better example, look at Platform::Exception in WinRT.natvis.

    You can use explicit field offsets and casting to access the hidden implementation from .natvis. I suppose it would technically qualify as exposing the implementation to the users in a roundabout way, but I don’t think that anyone would assume that a .natvis file defines any kind of contract that can be relied upon.

    Scot


    Developer Support Engineer

    Wednesday, June 19, 2013 6:36 PM
  • Hello,Scot Br:

         Now,I have met the same problem as you.I hope your problem has been solved.What is the last step to solve this problem?I hope you can give me a good solution.good luck.

    Thursday, May 9, 2019 8:49 AM