gcov y destructores globales

Question

EPM

#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; 

}

El problema

Compila el anterior con opciones -fprofile-arcs -ftest-coverage, RUNN el programa, y ​​luego corren gcov. La salida del programa muestra claramente que Foo :: Foo(), main() y Foo :: ~ Foo() se llaman, en ese orden. La salida de gcov muestra que Foo :: Foo() y main() son llamados, pero no Foo :: ~ Foo().

causa raíz

Los objetos globales son destruidos por un controlador de salida interna GNU (función registrada con at_exit()). Las estadísticas finales de gcov son producidas por otro manejador de salida. El controlador de salida de gcov obviamente se llama antes del controlador de salida de destrucción global, por lo que gcov no ve los destructores a los que se llama.

estado Bug

Ésta es una vieja, vieja error en gcov. Aquí está el enlace de Bugzilla: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7970. El error todavía existe nueve años más tarde, al menos en i686-apple-darwin10-g ++ - 4.2.1.

La pregunta

Es éste un error sin solución en gcov, algo que tengo que vivir con, o es sólo algo que pasó a deslizarse a través de las grietas (nueve años de edad y completamente olvidado)? Si es este último, ¿cómo solucionarlo?

Answer 1

En primer lugar, tenga en cuenta que ese informe de errores no se ha reconfirmado desde 2005; probablemente debería agregar una nota que diga que todavía está viendo el mal comportamiento en g ++ - 4.2.1. Incluso si nadie actúa en su mensaje, es útil tener esa información por ahí.

A corto plazo, si quiere seguir usando gcov, tiene que vivir con él. En su lugar, puede considerar lcov, que le permite excluir líneas específicas del análisis de cobertura. Advertencia justa: he oído que es bueno, pero nunca lo he usado.

De mediano plazo, agregue esa respuesta al rastreador de errores. Sin garantías, pero tal vez eso generará suficiente interés para que algún alma amable te escriba un parche.

A largo plazo, si nadie está dispuesto a parchearlo, es posible que pueda parchearlo usted mismo. gcc no es la base de código más amigable del mundo, y lograr que se acepten tus cambios puede ser una aventura, pero si realmente lo necesitas, puedes hacerlo realidad.

Lo mejor de la suerte.