J'ai des problèmes d'exécution et mon look de mon terminal comme: p> éditer: aussi, il ne génère pas le fichier Qu'est-ce qui se passe ici ? p> p> GPROF code> sur OS X. Le fichier
test.c code> est:
gmon.out code>. p>
3 Réponses :
Il sonne comme Test code> est construit à l'aide d'une architecture que
GPROF code> ne s'attend pas. Essayez ce qui suit:
$ cat > test2.c
#include <stdio.h>
int main() { printf("test\n"); return 0; }
^D
$ gcc -arch i386 -pg -o test2 test2.c
$ file test2
test2: Mach-O executable i386
$ ./test2
test
$ gprof test2
... bunch of output ...
$ gcc -arch ppc -pg -o test2 test2.c
$ file test2
test: Mach-O executable ppc
$ ./test2
test
$ gprof test2
gprof: file: test2 is not of the host architecture
$ arch -ppc gprof test2
... same bunch of output ...
Lorsque je compile avec -arch I386 ou -arch PPC, je reçois la même erreur de GProf (et aucun fichier Gmon.out n'est généré dans les deux cas)
C'est étrange ... généralement l'un ou l'autre fonctionnera. Quelle version du matériel et du système d'exploitation utilisez-vous? L'erreur est définitivement causée par une inadéquation entre l'architecture de l'exécutable et l'architecture hôte. Ceci est mentionné explicitement dans la page code> GPROF CODE> GPROF SOUS SUPPORT DE FICHIER UNIVERSAL I> SUR MON MACBOOK Pro - Intel Core 2 Duo, OS 10.5.7. Vous pouvez également utiliser arc code> sans argument pour voir quelle est l'architecture native et regarder
gcc -v code> pour voir ce que la spécification
- cible = code> pour le compilateur est.
J'utilise également le système d'exploitation 10.5.7, Intel Core 2 Duo. Appelant arc code> renvoie
i386 code> et
GCC -V code> montre
cible: i686-pomme-darwin9 code>
Vous pouvez essayer de faire un fichier gras en spécifiant plus d'une architecture. Quelque chose comme gcc -arch ppc -arch i686 -pg -o test test.c code> produit un binaire qui contient une architecture. GProf gère ce fichier sur mon système. D'après ce que vous dites,
gcc code> devrait produire une exécutable i686 qui est ce que
GPROF code> attend. Jetez un coup d'œil à la page code> man code> man '. Ils décrivent un tas de paramètres système différents (ENV et autres) qui pourraient changer cela.
Malheureusement, Mise à jour: strong> Il apparaît comme si GPROF code> ne fonctionne pas sur Mac OS X. Vous voudrez probablement utiliser
requin code>
à la place. Il fait partie des outils de développement dans / développeur / applications / outils de performance / requin code>. P>
GProf code> travaille maintenant sur Mac OS X 10.6 (Snow Leopard), en utilisant les derniers outils de développement. P>
Toute raison pour laquelle GProf ne fonctionne pas sur OS X? OS X n'est-il pas censé être unix pour les outils?
La série d'événements ici est censée fonctionner comme suit: P>
-pg code> option li>
- Code de liaison avec
-pg code> option li>
- PROGRAMME DE RUN LI>
- programme génère
gmon.out code> fichier li>
- Run
GPROF CODE> LI>
ol>
Le problème est que l'étape 4 n'arrive jamais. Il y a très peu d'informations sur cet échec spécifique. Le consensus général au cours des dernières années semble être que Apple préférerait utiliser le requin à la place, et ils ont été très laxistes sur la fixation de bugs et tels que GPROF code>. P>.
En bref: Installez Xcode, homme requin code> p>
Je vais devoir vérifier le requin. Je n'ai jamais eu de problème à obtenir un programme de générer gmon.out code> à condition que le programme sortait bien. IIRC, l'option de ligne de commande du profileur insère le code dans l'initialisation et la résiliation du temps d'exécution pour déclencher la capture de compteurs d'exécution et, finalement, l'écriture du fichier de sortie. Tant que le programme quitte le processus de retour de
principal code> ou explicite sur
quitter () code>, il devrait générer un fichier de sortie.
A-t-il généré le fichier gmon.out pour vous? Je ne suis pas capable de le faire avec votre exemple.
Non, ça ne le fait pas. J'ai oublié de vérifier cela. Je suppose que cela signifie que le problème commence plus tôt?