hello -- i've been trying hard to get my cygwin/gcc compiled program to play nice with my Windows version of vTune. The problem is that when i set up the call graph activity, it complains about my exe having been created without base relocations.
so the challenge seems to be figuring out how to get gcc to do the same thing that MS Visual Studio does with /fixed:no.
the vTune help file claims that all i need to do for gcc 2.95 is add the -g flag. my gcc is the latest downloadable from cygwin (~3.4) and plain -g doesn't work.
i've been googling all combination of terms i can think of to get this information, but i remain clueless.
I'd be surprised if Vtune help had any hints for Windows gcc. Linux icc is compatible with recent gcc, but not nearly as far back as 2.95. gcc can't support Microsoft style debugging, AFAIK. I'd suggest using cygwin gprof call graphing, with a supported version of gcc. VTune event based analysis of a cygwin build might be of some interest, but a liberal dose of good luck is needed.
Actually, the help does document use of gcc for Windows*! For this type of problem, the best thing might be to submit an issue at Intel Premier Support so that they can look into it. Additionally, if you can provide a sample app in source and binary with symbols, this will greatly speed up the process.
I just had the occasion to profile a cygwin gfortran 4.0.2 application. VTune was well behaved, up to the point of attempting to drill down to the gfortran run-time library source code. The source file chosen had no relation to the actual hot spot, which displayed correctly in asm view. The event counts related to the library function dot_product_r8() were allocated in source view in part to the call site, and part to an unrelated function in the library source, but correctly allocated in asm views. Usual optimizations in the library source code improved overall application performance by more than 20%. The VTune Help index didn't reveal any references to cygwin.
hello -- thanks for the help. i'll look into premier support sometime later today.
so the word in the vtune help system is under the heading "GNU* C/C++ Compiler for the Microsoft* Windows* Operating System". I assume this is what is meant by help for cygwin. however, it references gcc version 2.96 -- is it a problem if i'm using:
(this is the latest default gcc binary i downloaded through cygwin the other day)
i've tried three versions of my program. (actually, it's a sourceforge project called qmcbeaver, although i haven't updated the cvs with my recent stuff). all the versions i've compiled with -gstabs and -g3, as the help file suggests.
my three versions were: 1) with optimizations (-O3 -ffexpensive-optimizations -ffast-math) 2) without optimizations 3) without optimizations and without ATLAS math library
i was able to instrument all three with vtune so that i can run the call graph activity, but for all 3 i get the warning "Module does not contain base relocations." a popup message informs me about the /fixed:no change for use with visual studio -- but i've been unable to find an analogous makefile modification for gcc/cygwin. it's possible that this problem only affects call graph -- but call graph is the one i want info from...
when i run the call graph activity on my executables, it runs just fine, but none of my functions show up in the call list. only system dll functions show up -- and the graph attempts to build a tree out of cygwin1.dll, kernel32.dll, et al.
i would be happy to email one of my binaries if that might help, but there's really nothing unique about my program -- it's just a science program that crunches numbers.
lastly, here i'll paste the parameters from one of my makefiles: TAG = COMPILER = g++ LABEL = GCC_profile VERSION = 20050514 HOME = /home/Amos/QMcBeaver INCLUDE = -I$(HOME)/include FLAGS = -Wall -Wno-unused -Wno-unused-function -Wno-format DIROBJ = obj_$(LABEL) MAKE = make EXE = QMcBeaver.$(LABEL).$(VERSION).x DEPENDENCY = -MM OPTIMIZATION = DEBUG = PROFILE = -gstabs -g3 PARALLEL = LINK = -lm CXX = $(COMPILER) -DVERSION=$(VERSION) $(FLAGS) $(DEBUG) $(PROFILE) $(PARALLEL)
The first link is just enough to work out where the relocs will be needed, and puts the list into foo.base. Then dlltool will read this and generate foo.exp, which contains the reloc data. The second link will tie it all together again.
hello. i've just figured out how to fix my problem. if any of you intel people read this, you may want to include this information in a future update of the help manual since i've spent an amazing amount of time on this problem...
i'm pretty sure that i had already tried the -pie command with the gcc compiler before, but that didn't work. here is the final solution that works for me.
1) gcc needs the following two extra parameters: -Wl,-pie -pie the first tells ld to create a position independent executable, the second tells gcc to create position independent object files. it's possible that both aren't needed... but with both, my code works.
2) gcc also needs what the vtune help system already recommends: the -gstabs and -g3. without these, vtune can only do minimal instrumentation and for some reason wouldn't give me any results at all.