Comment tracer appel de fonction en C?

Sans modifier le code source, comment puis-je trace les fonctions qui sont appelées et avec quels paramètres de certaines fonctions(dites func100 dans l'exemple suivant) est invoquée. Je voudrais la sortie comme suit:

enter func100(p1001=xxx,p1002=xxx)
        enter func110(p1101=xxx,p1102=xxx)
        exit  func110(p1101=xxx,p1102=xxx)
        enter func120(p1201=xxx,p1202=xxx,p1203=xxx)
                enter func121(p1211=xxx)
                exit  func121(p1211=xxx)
        exit  func120(p1201=xxx,p1202=xxx,p1203=xxx)
exit  func100(p1001=xxx,p1002=xxx)

est-ce faisable? ou, quelle est la solution avec un minimum de modifications du code source?

source d'informationauteur Andrew

c call-hierarchy trace

14

Si vous utilisez gccvous pouvez utiliser le -finstrument-functions compilation drapeau.
Il ajoute du code qui appelle deux fonctions, __cyg_profile_func_enter et __cyg_profile_func_exit, chaque fois qu'une fonction d'entrée/sorties.

Vous aurez besoin de mettre en œuvre ces fonctions, à faire ce que vous voulez. Assurez-vous de les compiler, soit sans le drapeau, ou avec attribute((no_instrument_function))de sorte qu'ils ne essayez pas d'appeler eux-mêmes.

Les fonctions de " deuxième paramètre est un pointeur vers le site d'appel (c'est à dire l'adresse de retour dans la fonction appelante). Vous pouvez simplement imprimer avec %pmais il sera un peu difficile à utiliser. Vous pouvez utiliser nm de comprendre la fonction réelle qui contient cette adresse.

Vous ne pouvez pas obtenir les paramètres de la fonction de cette façon.

Avec la Bibliothèque C de GNU, vous pouvez utiliser le trace module. Voici un exemple:

#include <stdio.h>
#include <execinfo.h>
#include <stdlib.h>


void handler(char *caller) {
  void *array[10];
  size_t size;
  printf("Stack Trace Start for %s\n",caller);
  size = backtrace(array, 10);
  backtrace_symbols_fd(array, size, 2);
  printf("Stack Trace End\n");
}

void car() {
    handler("car()");
    printf("Continue Execution");
}
void baz() {car(); }

void bar() { baz(); }
void foo() { bar(); }


int main(int argc, char **argv) {
  foo(); 
}

compiler avec -g -rdynamic compilateur option pour charger les symboles

gcc -g -rdynamic Test1.c -o Test

Vous verrez une sortie similaire à

Stack Trace Start for car()
./Test(handler+0x2d)[0x80486f1]
./Test(car+0x12)[0x804872e]
./Test(baz+0xb)[0x8048747]
./Test(bar+0xb)[0x8048754]
./Test(foo+0xb)[0x8048761]
./Test(main+0xb)[0x804876e]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x126e37]
./Test[0x8048631]
Stack Trace End
Continue Execution in car

Vous pouvez écrire cette fonction de gestionnaire et de l'appeler à partir de n'importe où dans votre programme à n'importe quel nombre de fois. N'oubliez pas d'augmenter le array taille comme requis.

4

Si vous êtes sur linux, callgrind pourrait aider. Essentiellement, il recueille des statistiques de ce que vous cherchez, alors, il pourrait fournir un moyen d'accéder à ses données brutes.
3

Utiliser un débogueur pour définir des points d'arrêt avec les actions associées. Par exemple, dans gdb, vous pouvez définir un point d'arrêt au début et à la fin de chacune des fonctions que vous voulez tracer. Vous pouvez donner à chacun de ces points d'arrêt d'une commande à exécuter, telles que:
```
printf("Enter func100(p1001=%d, p1002=%d)", p1001, p1002)
```
Puis, lorsque vous exécutez le programme (dans le débogueur) il va imprimer le texte de chacune de vos commandes avec les paramètres associés.

Prendre un coup d'oeil à la la documentation pertinente pour gdb.
1

Parfois je trace beaucoup d'appels de fonction, même pour les librairies externes, je n'ai pas de contrôle, ou je ne veux pas modifier.

Il y a quelque temps, j'ai réalisé que vous pouvez combiner gdb expression régulière des points d'arrêt (réguliers sont ok, trop) et puis il suffit d'exécuter une série de commandes à exécuter à chaque fois que ces points d'arrêt sont déclenchées. Voir: http://www.ofb.net/gnu/gdb/gdb_35.html

Par exemple, si vous souhaitez suivre toutes les fonctions qui commencent par "MPI_" préfixe, vous pouvez le faire:
```
(gdb) rbreak MPI_
[...]
(gdb) command 1-XX
(gdb) silent
(gdb) bt 1
(gdb) echo \n\n
(gdb) continue
(gdb) end
```
De commande en mode silencieux est utilisé pour masquer gdb messages lorsqu'un point d'arrêt est trouvé.
J'ai l'habitude d'imprimer un couple de lignes vides, de sorte qu'il est plus facile à lire.

Ensuite, il suffit de lancer le programme:
(gdb) run

Une fois au début de votre programme en cours d'exécution, gdb va imprimer le N supérieur backtrace niveaux.
```
#0  0x000000000040dc60 in MPI_Initialized@plt ()


#0  PMPI_Initialized (flag=0x7fffffffba78) at ../../src/mpi/init/initialized.c:46


#0  0x000000000040d9b0 in MPI_Init_thread@plt ()


#0  PMPI_Init_thread (argc=0x7fffffffbe78, argv=0x7fffffffbde0, required=3, provided=0x7fffffffba74) at ../../src/mpi/init/initthread.c:946


#0  0x000000000040e390 in MPI_Comm_rank@plt ()


#0  PMPI_Comm_rank (comm=1140850688, rank=0x7fffffffba7c) at ../../src/mpi/comm/comm_rank.c:53


#0  0x000000000040e050 in MPI_Type_create_struct@plt ()


#0  PMPI_Type_create_struct (count=3, array_of_blocklengths=0x7fffffffba90, array_of_displacements=0x7fffffffbab0, array_of_types=0x7fffffffba80, newtype=0x69de20) at ../../src/mpi/datatype/type_create_struct.c:116


#0  0x000000000040e2a0 in MPI_Type_commit@plt ()


#0  PMPI_Type_commit (datatype=0x69de20) at ../../src/mpi/datatype/type_commit.c:75
```
Si vous souhaitez des informations plus détaillées, l'impression des variables locales d'un point d'arrêt est également possible, il suffit d'insérer plus de commandes entre command et end.

Bonus astuce: ajouter à votre .gdbinit fichier et le tuyau de l'exécution dans un fichier.

J'ai aussi rencontré ce problème d'avoir de bonnes appel de la fonction trace. Donc, j'ai écrit un Python GDB script (https://gist.github.com/stettberger/e6f2fe61206471e22e9e6f1926668093) qui définit un point d'arrêt sur chaque fonction intéressante (défini par la variable d'environnement TRACE_FUNCTION). GDB appelle ensuite la fonction python qui décode le cadre et l'ensemble de ses arguments. Si elle rencontre un pointeur, il essaie de déréférencement d'elle et donc de l'impression d'un appel de fonction trace pour TRACE_FILE (par défaut: /tmp/log) avec des arguments. Pour le programme suivant

#include <stdio.h>

struct foo {
    int a;
    struct foo * next;
};

int fib(int a, struct foo *b) {
    if (a <= 1) return 1;
    printf("%d\n", a);
    return fib(a-1, 0)+fib(a-2, 0);
}

int main() {
    struct foo b = {23, 0};
    return fib(5, &b);
}

Je avoir un suivi détaillé, où chaque ligne est un python tuple qui peut être lu avec eval():

('call', None, 1, 'main', 'main', {})
('call', 1, 2, 'fib', 'fib', {'a': {'type': 'int', 'value': 5}, 'b': {'type': 'struct foo *', 'value': 140737488344320, 'deref': {'type': 'struct foo', 'value': {'a': {'type': 'int', 'value': 23}, 'next': {'type': 'struct foo *', 'value': 0, 'deref': None}}}}})
('call', 2, 3, 'fib', 'fib', {'a': {'type': 'int', 'value': 4}, 'b': {'type': 'struct foo *', 'value': 0, 'deref': None}})
....
('return', 'fib', 2, {'type': 'int', 'value': 8})
('exit', 8)

L'essentiel contient plus d'informations sur le format de fichier journal.

0

Vous pouvez regarder dans log4cxx, un projet hébergé par la fondation apache. Je sais que log4j, la java variante vous a permis de régler la sensibilité, et vous pourrez suivre chaque chose qui a été fait dans le programme. Peut-être que le c++ variante est le même, mais il y a plusieurs alternatives-il y a un aspect orienté compilateur c++, et vous pouvez définir un aspect dans l'ensemble des fonctions, et de les attraper et de les imprimer les variables. Une autre alternative est d'utiliser un débogueur.

Pour résumer: un débogueur, log4cxx ou AOP
0

Si vous utilisez des modules dynamiques, vous pouvez obtenir cette info avec la commande ltrace. Vous pouvez même spécifier le regardé la bibliothèque avec l'option-l

Vous devez vous connecter pour publier un commentaire.