VTune unabled to find source code when code compiled with multiple targets.

[LLess]

I have a project which compiled using the Intel Compiler (Windows 7x64)

/QaxSSE2,SSE3,SSSE3,SSE4.1,SSE4.2

When I do that some of my functions are not detected in VTune. It just shows me the dll name where  the code resides and I can't even dig into the code.

However if I remove the /Qax code and force only SSE4.2 for example using /QxSSE4.2 then suddenly everything is displayed properly.

In Visual Studio I can put breakpoint in the code whatever option was used. So it seems to be able to detect where the code is.

But somehow I think that VTune isn't able to do that properly.

A bit annoying but at least I know that I need to disable that option when I want to profile my code now.

My Configuration:

Windows 7 x64

Visual Studio 2008 (or 2010)

Intel Composer XE 2011 SP1

VTune Amplifier XE 2013 Update 5.

Laurent

[SergeyKostrov]

Could you create a small reproducer of the problem? it really could help to understand what is wrong. Thanks in advance.

[LLess]

Not sure. The code is part of a huge library and extracting some parts will be really tricky.

And on top of that it is some quite restricted code so I would probably have to write something completely different....

Since I have a work around, I just wanted to raise the attention to the issue.

Laurent

[SergeyKostrov]

>>...And on top of that it is some quite restricted code so I would probably have to write something completely different... This is exactly what I asked for. So, ideally it has to be a completely standalone small VS solution with two small projects ( for exe and dll ) and it should reproduce your problem. I didn't ask for any extraction of existing codes, etc.

[LLess]

Well I understood that :)

But not understanding what is going wrong in the first place except that I am not getting VTune finding the function is making pretty difficult to write some completely different code to reproduce the issue...

We (the company) have an NDA with Intel so I could probably package you the binary that I am testing but that would be quite big.

Laurent

[SergeyKostrov]

>>...We (the company) have an NDA with Intel so I could probably package you the binary that I am testing but >>that would be quite big... Thanks for the update. I think in that case you need to make a request to the Intel Premier support.

[Bernard]

Can you inspect the dll exports with dumpbin?VTune resolves code sections by sampling instruction pointer and probably checks also dll or exe pdb section.So maybe there is problem with pdb files of your library dll?

[LLess]

I will check that but since Visual Studio is able to put a break point in the function and stop at the right location, I am fairly confident that the PDBs and debug informations are correct.

Also only turning off the QaX option fixes the issue, so I am quite sure that this is what is causing the problem.

[Peter_W_Intel]

As I know that if build with "/Qax-" option with Intel C++ Compiler, it will generate two suites of binar ycode (SSE4.2 binary and non-SSE4.2 binary - for example), binaries are flexible to run on SSE4.2 supported platform or on old platform. Thus, there is no fixed function entry address in debug info (actually there are two *real* entries...probably there is one "pseudo" function entry where the binary will detect running processor first, then jump to righ functio location. That is why it was hard to map to right function and the tool got confused:-(     

[LLess]

Yes that it is also my understanding about the /Qax option. I was just hoping that both being Intel Products VTune would have been able to take care of that :)

[Bernard]

I do not think that VS debugger will rely on pdb files to put breakpoint maybe it is pulling the information from pdb files to resolve callstack, but putting a breakpoint is done by writing debugee virtual adress space and inserting int 3 instruction at specific address.

[SergeyKostrov]

>>...I do not think that VS debugger will rely on pdb files to put breakpoint maybe... In that case why does it need at all?

[Bernard]

Probably to resolve callstack functions names and other debugging information..

[David_A_Intel1]

Thanks for your post, Laurent.

Regarding your problem, it should be simple enough to build one of the VTune Amplifier XE samples with these compiler options and reproduce the problem.  I'll see if I can have a colleague look at this, as I am heading out on vacation.

[Holly_W_Intel]

At MrAnderson's request, I tried this with our sample code and could not reproduce the problem.

I have a question. In your initial note you say you are using Intel Composer XE 2011, SP1. Is there a reason why you are not using Composer XE 2013? (That is what I have on the machine I am testing on).

[LLess]

Well I do have the Composer XE 2013 but we are not using it for that branch of the code.

Actually that is a good point, I will try to see if I can build my code with it and see if it causes the same problem.

[LLess]

Ok, I have been able to build my code with Composer XE 2013 and the has been fixed apparently.

You can ignore the issue then. Damn I should have thought about it.

I am still not really happy with the code produced by both compilers but that is another issue (and that is what happens when you have done too much assembly coding in the past, compiled code can look ugly ;)

Thanks.

Laurent

[SergeyKostrov]

>>...I am still not really happy with the code produced by both compilers but that is another issue... Laurent, Please follow up with technical details on Intel C++ compiler forum if you think there are some issues with generated codes. Right now your statement is too generic. Thanks in advance.

[LLess]

I know :) I will if I can't go around the issue.

Laurent.