topic I know :) I will if I can't in Analyzers

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

LLess — Thu, 09 May 2013 02:14:24 GMT

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

Could you create a small

SergeyKostrov — Thu, 09 May 2013 04:27:00 GMT

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

Not sure. The code is part of

LLess — Thu, 09 May 2013 04:32:03 GMT

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

>>...And on top of that it is

SergeyKostrov — Thu, 09 May 2013 05:07:59 GMT

>>...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.

Well I understood that :)

LLess — Thu, 09 May 2013 05:11:53 GMT

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

>>...We (the company) have an

SergeyKostrov — Thu, 09 May 2013 05:19:07 GMT

>>...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.

Can you inspect the dll

Bernard — Thu, 09 May 2013 06:34:14 GMT

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?

I will check that but since

LLess — Thu, 09 May 2013 06:37:37 GMT

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.

As I know that if build with

Peter_W_Intel — Thu, 09 May 2013 07:59:50 GMT

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:-(

Yes that it is also my

LLess — Thu, 09 May 2013 08:02:06 GMT

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 :)

I do not think that VS

Bernard — Thu, 09 May 2013 08:51:13 GMT

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.

>>...I do not think that VS

SergeyKostrov — Thu, 09 May 2013 12:26:34 GMT

>>...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?

Probably to resolve callstack

Bernard — Thu, 09 May 2013 15:00:33 GMT

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

Thanks for you post, Laurent.

David_A_Intel1 — Thu, 09 May 2013 15:16:00 GMT

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.

At MrAnderson's request, I

Holly_W_Intel — Thu, 09 May 2013 16:25:26 GMT

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).

Well I do have the Composer

LLess — Thu, 09 May 2013 23:33:02 GMT

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.

Ok, I have been able to build

LLess — Fri, 10 May 2013 00:05:27 GMT

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

>>...I am still not really

SergeyKostrov — Fri, 10 May 2013 00:49:15 GMT

>>...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.

I know :) I will if I can't

LLess — Fri, 10 May 2013 00:50:07 GMT

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

Laurent.