- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
1 Solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
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).
Link Copied
5 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Thanks!
Dale
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
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
Thanks!
Dale
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page