2012-03-03 17 views
17

Come è possibile elencare tutte le funzioni richiamate in un'applicazione. Ho provato a utilizzare GDB ma la sua lista di backtrace solo fino alla chiamata della funzione principale.Elenco di tutte le chiamate di funzione effettuate in un'applicazione

Ho bisogno di una lista più profonda l'elenco di tutte le funzioni chiamate dalla funzione principale e dalla funzione chiamata da queste funzioni chiamate e così via.

C'è un modo per ottenere questo in gdb? O potresti darmi suggerimenti su come ottenere questo?

+0

Con qualsiasi strumento: http://stackoverflow.com/questions/311840/tool-to-trace-local-function-calls-in-linux?lq=1 –

+0

Possibile duplicato di [Esegui il flusso di controllo di stampa GDB delle funzioni come vengono chiamate] (http://stackoverflow.com/questions/311948/make-gdb-print-control-flow-of-functions-as-the--- chiamato) – jww

+0

https://balau82.wordpress.com/2010/10/06/trace-and-profile-function-calls-with-gcc/ –

risposta

17

Come possiamo elencare tutte le funzioni chiamati in un'applicazione

Per qualsiasi applicazione realisticamente dimensioni, questa lista avrà migliaia di voci, che probabilmente renderà inutile.

Puoi trovare tutte le funzioni definite (ma non necessariamente chiamato) in un'applicazione con il comando nm, per esempio

nm /path/to/a.out | egrep ' [TW] ' 

È inoltre possibile utilizzare GDB per impostare un punto di interruzione ogni funzione:

(gdb) set logging on  # collect trace in gdb.txt 
(gdb) set confirm off # you wouldn't want to confirm every one of them 
(gdb) rbreak .   # set a breakpoint on each function 

Una volta si continua, ti ha colpito un punto di interruzione per ogni funzione chiamata. Utilizzare i comandi disable e continue per andare avanti. Non credo che ci sia un modo semplice per automatizzarlo, a meno che tu non voglia usare lo scripting Python.

Già menzionato gprof è un'altra buona opzione.

+0

Nota: questo si interromperà anche sul codice eseguito prima di '_start': http : //stackoverflow.com/questions/31379422/why-is-init-from-glibcs-csu-init-first-c-called-before-start-even-if-start-i –

+0

gdb è al 100% cpu da quando ho inserito il comando 'rbreak .' –

+0

senza registrazione,' set height 0' sarà utile (nessuna paginazione per l'output) – Blauhirn

9

Vuoi un grafico di chiamata. Lo strumento che si desidera utilizzare non è gdb, è gprof. Compilare il programma con -pg e quindi eseguirlo. Quando viene eseguito un file, verrà prodotto gmon.out. Quindi elaborare questo file con gprof e godersi l'output.

1

Questa domanda potrebbe richiedere un chiarimento per decidere tra le attuali 2 risposte. Dipende da ciò che è necessario:

1) È necessario sapere quante volte ogni funzione viene chiamata in formato elenco lineare/grafico di funzioni corrispondenti al numero di chiamate. Ciò potrebbe portare a risultati ambigui/inconcludenti se il tuo codice non è procedurale (cioè funzioni che chiamano altre funzioni in una struttura esterna senza ambiguità di ciò che sta chiamando cosa). Questa è la funzionalità di base di gprof che richiede la ricompilazione con il flag -pg.

2) Avete bisogno di un elenco di funzioni nell'ordine in cui sono stati chiamati, questo dipende dal programma che è il migliore/un'opzione fattibile: a) se il vostro programma viene eseguito e termina senza errori di runtime è possibile utilizzare gprof per questo scopo. b) L'opzione ELSE sopra usando dbg con i punti di log e break è l'opzione di sinistra che ho imparato leggendo questo.

3) È necessario conoscere non solo l'ordine ma, ad esempio, gli argomenti della funzione per ogni chiamata. Il mio attuale lavoro sono le simulazioni in fisica del trasporto di particelle, quindi questo sarebbe ASSOLUTAMENTE utile nel rintracciare i risultati anomali che provengono da ... cioè quando gli argomenti che vengono fatti passare smettono di avere un senso.Immagino che un modo per farlo è sarebbe una variazione su quello Impiegato russo ha fatto eccezione con la seguente:

(gdb) informazioni args

registrare i risultati di questo comando con ogni punto di rottura (impostato su ogni chiamata di funzione) fornisce gli argomenti della funzione corrente.

4

record di funzione-call-storia

https://sourceware.org/gdb/onlinedocs/gdb/Process-Record-and-Replay.html

Questo dovrebbe essere un grande accelerazione hardware possibilità se siete una delle poche persone (2015) con una CPU che supporti Intel Processor Tracing (Intel PT, intel_pt in /proc/cpuinfo).

GDB documenti sostengono che esso può produrre un output simile:

(gdb) list 1, 10 
1 void foo (void) 
2 { 
3 } 
4 
5 void bar (void) 
6 { 
7  ... 
8  foo(); 
9  ... 
10 } 
(gdb) record function-call-history /ilc 
1 bar  inst 1,4  at foo.c:6,8 
2 foo inst 5,10 at foo.c:2,3 
3 bar  inst 11,13 at foo.c:9,10 

Prima di utilizzarlo è necessario eseguire:

start 
record btrace 

che è dove una CPU non in grado fallisce con:

Target does not support branch tracing. 

Il supporto CPU è ulteriormente discusso a: How to run record instruction-history and function-call-history in GDB?

discussioni correlate:

per embedded, si considera anche JTAG e hardware di supporto, come ARM DSTREAM, ma il supporto x86 non sembra molto buona: debugging x86 kernel using a hardware debugger

Problemi correlati