Code coverage for dynamic libraries (DLLs)

[kwilk]

Is there any way to obtain *.dpi files for dynamic library (DLL; esp. interested in COM/DCOM case) compiled with Intel C++ but called from an application not built with icc?

Assuming that it is possible: how to do it?

I had tried to provide paths for *.dpi files when compiling, I had set env variable and there were no *.dpi files generated when running these instrumented DLLs.

I hope there is a way to do it. Please share your experiences.

[Dale_S_Intel]

I think it should just work, i.e. if you build the DLL with /Qprof-gen then when it is executed, the .dpi file should be generated when the app finishes or when the DLL is detached. It should show up in your prof-dir, depending on how that was set. If you're not seeing that behavior, let me know and I'll see if maybe there's a problem or confusion somewhere.

Thanks!

Dale

[kwilk]

Unfortunately, it does not work. Closer investigation (with ProcMon) lead to a conclussion that regsvr32 is not able to register the DLL properly and therefore it is not visible as a COM interface in the system. Funny thing is that with some DLL-examining tools you will find (expected) exported functions and nothing else whereas regsvr32 attempts to load a lot of weird names while loading the DLL. E.g.
Docf_DocumentSummaryInformation
DocumentSummaryInformation
SebiesnrMkudrfcoIaamtykdDa
Docf_SebiesnrMkudrfcoIaamtykdDa
SebiesnrMkudrfcoIaamtykdDa
OzngklrtOwudrp0bAayojd1qWh
etc.

What am I missing? I compile the code with Intel in the same manner (+coverage options) as with VC9 and VC9 DLL just works.


Quoting - Dale Schouten (Intel)

I think it should just work, i.e. if you build the DLL with /Qprof-gen then when it is executed, the .dpi file should be generated when the app finishes or when the DLL is detached. It should show up in your prof-dir, depending on how that was set. If you're not seeing that behavior, let me know and I'll see if maybe there's a problem or confusion somewhere.

Thanks!

Dale

[Brandon_H_Intel · Accepted solution]

Before getting into this further, I should clarify that using code coverage or /Qprof-gen, the instrumented executable creates .dyn files, not .dpi files. The .dpi file is created later by the profmerge utility (or if you are using /Qprof-use, profmerge is called automatically).

I'm pretty sure we've had customers that use a similar model to this. Usually it's some executable written in Visual Basic or C# or Python that calls a C++ dll, and I believe that has worked in the past. The first question would be to take a look at the error code being returned from regsvr32 and see why it's failing to register the dll. After that, try to get a test case that we can reproduce on our end. The process of narrowing down the problem may uncover workarounds for you too. The first thing I'd try is removing or disabling key compiler options to see if they make a difference (first remove /Qprof-gen, then try using /Od instead of the default optimization, and so on).

[kwilk]

Thanks for hints. I managed to narrow down the issue - it was related to manifest not being included in the DLL.
The build required one additional step: adding the manifest using mt.exe tool (from MS Platform SDK).
After merging the manifest in the DLL is being loaded by Excel and the *.dyn files are created in the directory they are supposed to.

[Brandon_H_Intel]

Quoting - kwilk

Thanks for hints. I managed to narrow down the issue - it was related to manifest not being included in the DLL.
The build required one additional step: adding the manifest using mt.exe tool (from MS Platform SDK).
After merging the manifest in the DLL is being loaded by Excel and the *.dyn files are created in the directory they are supposed to.

Oh, of course, that makes sense. Glad to hear you're back up and running.