GCOV e distruttori globali

Question

MWE

#include <iostream>

struct Foo {
  Foo() {
    std::cout << "Constructing Foo " << this << std::endl;
  }

  ~Foo() {
    std::cout << "Destructing Foo " << this << std::endl;
  }
};

Foo global_foo;

int main () {
  std::cout << "Entering and exiting main()" << std::endl;
  return 0;

}

Il problema

Compila quanto sopra con le opzioni -fprofile-arcs -ftest-coverage, eseguire il programma e quindi eseguire GCOV. L'output del programma mostra chiaramente che foo :: foo (), main () e foo :: ~ foo () sono chiamati, in quell'ordine. L'output GCOV mostra che foo :: foo () e main () sono chiamati, ma non foo :: ~ foo ().

Causa ultima

Gli oggetti globali vengono distrutti da un gestore di uscita interno GNU (funzione registrata con AT_EXIT ()). Le statistiche GCOV finali sono prodotte da un altro gestore di uscita. Il gestore di uscita GCOV è ovviamente chiamato prima del gestore di uscita della distruzione globale, quindi GCOV non vede i distruttori chiamati.

Stato di bug

Questo è un vecchio, vecchio bug in GCOV. Ecco il link Bugzilla: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7970. Il bug esiste ancora nove anni dopo, almeno in I686-Apple-Darwin10-G ++-4.2.1.

La domanda

Questo è un bug irrisolvibile in GCOV, qualcosa con cui devo convivere, o è solo qualcosa che è successo a scivolare attraverso le crepe (nove anni e completamente dimenticato)? Se quest'ultimo, come risolverlo?

Answer 1

Prima di tutto, si noti che quel rapporto di bug non è stato riconfermato dal 2005; Probabilmente dovresti aggiungere una nota che dice che stai ancora vedendo il cattivo comportamento in G ++-4.2.1. Anche se nessuno agisce sul tuo messaggio, è utile avere tali informazioni là fuori.

A breve termine, se vuoi continuare a usare GCOV devi conviverci. Potresti considerare lcov Invece, che ti dà la possibilità di escludere le linee specifiche dall'analisi della copertura. Avviso equo: ho sentito che è bello, ma non l'ho mai usato da solo.

Medio termine, aggiungi quella risposta al tracker di bug! Nessuna garanzia, ma forse questo genererà abbastanza interesse per un'anima gentile per scriverti una patch.

A lungo termine, se nessuno è disposto a ripararlo per te, potresti essere in grado di ripararlo da solo. GCC non è la base di codice più amichevole del mondo e ottenere le modifiche accettate può essere un'avventura, ma se ne hai davvero bisogno, puoi farlo accadere.

Buona fortuna.