Pytanie w sprawie gcov, gcc – gcov nie generuje plików gcda

4

Próbowałem uruchomić gcov za pomocą-fprofile-arcs & -ftest-coverage i nic do łączenia.

Podawał ten błąd: -

<code> hidden symbol `__gcov_init' in /home/mojave/tools/gcc-4.4.1/amd64/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.1/libgcov.a(_gcov.o) is referenced by DSO
</code>

i program kończy działanie.

Polecenie do kompilacji

<code>bsub -g /mojave/build/"DummyDate" -J compile-obj/linux24rhel3_x86_64_GCOV64/DXp.o -I -q DFM -S 8192 -R "(model==OPTERON_250)" '/usr/bin/time --format="          ...finished DXp [`hostname`] [%E s with %P CPU]"  /home/mojave/tools/gcc-4.4.1/amd64/bin/g++ -fPIC -Wall -Wno-deprecated -DTCL_8_5 -m64 -march=opteron -DLITTLE_ENDIAN_PLATFORM -DARCH=amd64 -DARCH_amd64 -DARCH_BITS=64 -DARCH_BITS_64 -fsigned-char -msse3 -D__DISABLE_MULTITHREAD__ -D_CPP_NUMERIC_LIMITS -mfpmath=sse,387 -mmmx -m3dnow -pipe -Dgcc -DLICENSE_ALWAYS_GOOD -I/home/mojave/tools/flexlm/include/v8.4 -DNO_SUPPORT_STABIE -DGCOV -I../dxpclient -I/home/mojave/tools/bzip2-1.0.2/amd64/include -I/home/mojave/tools/zlib-1.2.3/amd64/include -I/home/mojave/tools/tcltk8.5.2/amd64//include -I/home/mojave/tools/tcltk8.5.2/amd64//include -g -fprofile-arcs -ftest-coverage -DBUILD_DATE=\""UNSET"\" -DVERSION_NUMBER=\"Dum.Dum.Dum.Dummy\" -DEXT_VERSION_NUMBER=\"Dum.Dum.Dum.Dummy\" -DLAST_RELEASE_VERSION=\"1.1614\" -Wreturn-type -DTCL_8_5 -DGOOGLE_MALLOC -L../dx/linux24rhel3_x86_64_GCOV64/ -ldx -o obj/linux24rhel3_x86_64_GCOV64/DXp obj/linux24rhel3_x86_64_GCOV64/DXp.o -Wl -lgcov /home/mojave/tools/zlib-1.2.3/amd64/lib/libz.a  -L/home/mojave/tools/bzip2-1.0.2/amd64/lib -lbz2    -ldl'
</code>

Każda pomoc zostanie doceniona dzięki głosowaniu.

Dzięki.

Czy możesz pokazać nam plik Makefile lub ciąg kompilacji? Jest całkiem możliwe, że dołączasz flagi profilu do niewłaściwego obiektu docelowego. Shrey

Twoja odpowiedź

3   odpowiedź
0

crazy_prog, sprawdź „ścieżkę”. Podczas pobierania zasięgu za pomocą lcov / gcov ścieżka odgrywa ważną rolę.

Dlatego ścieżka, w której utworzyłeś plik binarny (pełny ciąg ścieżki), i ścieżka, w której uruchamiasz plik binarny, powinny być dokładnie takie same.

Dla mojego celu, ponieważ tworzenie pliku binarnego i wykonywanie pliku binarnego odbywa się w różnych miejscach (jedno w środowisku programistycznym i inne w rzeczywistej tablicy), więc używając softlink / skrótów, tworzę podobną ścieżkę, a zatem uruchamiam plik wykonywalny. Wreszcie można wygenerować raport w środowisku programistycznym (zwykle, ponieważ rzeczywista platforma na pokładzie może nie mieć obsługi narzędzi lcov).

9

-fprofile-arcs i-ftest-coverage. -lgcov podczas generowania współdzielonego obiektu. To będzie działać.

Możesz także użyć--coverage opcja jako synonim wszystkich trzech kroków

Patrzeć na:opcje oprzyrządowania gcc po więcej informacji

@ naive231 Osobiście miałem ten problem, ponieważ miałem nieskończoną pętlę for (;;) na końcu mojej głównej metody. Program musi wyjść, aby pliki gcda były poprawnie generowane. user3062913
Próbuję tego polecenia, ale nadal nie ma pliku gcda:g++ -fprofile-arcs -ftest-coverage -lgcov main.cpp  Czy tęsknię za czymś innym? naive231
Uwaga: używanie--coverage ponieważ kompilacja i link automatycznie przekładają się na flagi, które dajesz. Jest to konwencja oferowana przez gcc, aby ułatwić sobie sprawę. Również przyszłościowe. Cieszyć się ! Offirmo
0

że jeśli wyślę sig kill lub sig term do mojego programu, TYLKO PLIKI GCNO SĄ WYKONANE, bez plików gcda.

Powiązane pytania