Come posso ottenere perf a trovare i simboli nel mio programma

Question

Quando si utilizza perf report, non vedo alcun simbolo per il mio programma, invece ottengo output come questo:

$ perf record /path/to/racket ints.rkt 10000 
$ perf report --stdio 

# Overhead Command  Shared Object Symbol 
# ........ ........ ................. ...... 
# 
    70.06% ints.rkt [unknown]   [.] 0x5f99b8   
    26.28% ints.rkt [kernel.kallsyms] [k] 0xffffffff8103d0ca 
    3.66% ints.rkt perf-32046.map  [.] 0x7f1d9be46650 

che è abbastanza uninformative.

Il programma pertinente è costruito con i simboli di debug e lo strumento sysprof mostra i simboli appropriati, così come Zoom, che credo utilizzi perf sotto il cofano.

Si noti che questo è su x86-64, quindi il file binario è compilato con , ma questo è il caso quando si esegue anche sotto gli altri strumenti.

Answer 1

E il tuo computer host? È anche in esecuzione il sistema operativo x86_64? In caso contrario, assicurati che il perf sia compilato in modo incrociato, perché il perf dipende dall'objdump e da altri strumenti in toolchain.

Answer 2

È sempre possibile utilizzare il comando '$ nm'.

Ecco qualche esempio di output:

Ethans-MacBook-Pro:~ phyrrus9$ nm a.out 
0000000100000000 T __mh_execute_header 
0000000100000f30 T _main 
       U _printf 
0000000100000f00 T _sigint 
       U _signal 
       U dyld_stub_binder 

Answer 3

Assicurarsi che si compila il programma utilizzando l'opzione -g insieme a gcc (cc) in modo che le informazioni di debug è prodotta in formato nativo del sistema operativo. Provare a fare quanto segue e controllare se ci sono simboli di debug presenti nella tabella dei simboli.

$objdump -t your-elf 
$readelf -a your-elf 
$nm -a your-elf 

Answer 4

ho avuto lo stesso problema con perf dopo sovrascrivendo il nome del mio programma via prctl(PR_SET_NAME)

Come posso vedere il tuo caso è molto simile:

70,06% int. rkt [unknown]

Comando hai eseguito (racchetta) è diverso da quello perf hanno visto.

Answer 5

è possibile verificare il valore di kptr_restrict per . Se gli indirizzi dei simboli nel risultato sono tutti 0x000000, è possibile correggerli tramite il comando echo 0 > sys/kernel/kptr_restrict. Dopo questo, potresti ottenere il risultato desiderato di perf report

Answer 6

Questo post ha già più di un anno, ma poiché è uscito nella parte superiore dei risultati di ricerca di Google quando ho avuto lo stesso problema, ho pensato che avrei rispondi qui Dopo qualche ricerca in più, ho trovato il answer given in this related StackOverflow question molto utile.Sul mio sistema Ubuntu Raring, poi ho finito per fare il seguente:

1. Compilare le mie fonti C++ con -g (abbastanza ovvio, è necessario simboli di debug)

2. Run perf come

   record -g dwarf -F 97 /path/to/my/program 
   

   Questo way perf è in grado di gestire il formato di debug DWARF 2, che è il formato standard gcc utilizzato su Linux. Il parametro -F 97 riduce la frequenza di campionamento a 97 Hz. La frequenza di campionamento di default era apparentemente troppo grande per il mio sistema e ha portato in messaggi come questo:

   Warning: 
   Processed 172390 events and lost 126 chunks! 
   
   Check IO/CPU overload! 
   

   e la chiamata perf report poi sarebbe fallire con un errore di segmentazione. Con la frequenza di campionamento ridotta, tutto ha funzionato bene.

3. Una volta che il file perf.data è stato generato senza errori nel passaggio precedente, è possibile eseguire perf report ecc. Personalmente mi piacciono gli strumenti FlameGraph per generare visualizzazioni SVG.

4. Other people riferito che l'esecuzione

   echo 0 > /proc/sys/kernel/kptr_restrict 
   

   come root può aiutare pure, se sono necessari i simboli del kernel.

Answer 7

Ho avuto anche questo problema, non sono riuscito a vedere alcun simbolo dello spazio utente, ma ho visto alcuni simboli del kernel. Pensavo che questo fosse un problema di caricamento di simboli. Dopo aver provato tutte le possibili soluzioni che ho trovato, non riuscivo ancora a farlo funzionare.

Poi mi ricordo che vagamente

ulimit -u illimitato

è necessario. Ho provato e ha funzionato magicamente.

Ho trovato da questo wiki che questo comando è necessario quando si utilizzano troppi descrittori di file.

https://perf.wiki.kernel.org/index.php/Tutorial#Troubleshooting_and_Tips

mio comando finale è stato

perf record di 999 -F-g ./my_program

non ha bisogno --call-grafico