Correla origine con elenco assembly di un programma C++

Question

L'analisi del core dump nella build di vendita al dettaglio richiede spesso di correlare lo objdump di qualsiasi modulo specifico e l'origine. Normalmente correlare la discarica di assembly con la sorgente diventa un dolore se la funzione è abbastanza coinvolta. Oggi ho provato a creare un assembly listing di un particolare modulo (con l'opzione di compilazione -S) in attesa di vedere una sorgente di interleaving con assembly o una correlazione. Purtroppo l'elenco non è stato abbastanza gentile di correlare quindi mi chiedevo

• Dato un core-discarica da cui è possibile determinare la posizione incidente
• objdump del modulo non aver Assemblea Inserite da ricompilare il modulo di
• con Opzione -S.

È possibile eseguire una corrispondenza uno a uno con la fonte?

Come esempio vedo la lista di montaggio come

.LBE7923: 
     .loc 2 4863 0 
     movq %rdi, %r14 
     movl %esi, %r12d 
     movl 696(%rsp), %r15d 
     movq 704(%rsp), %rbp 
.LBB7924: 
     .loc 2 4880 0 
     testq %rdx, %rdx 
     je  .L2680 
.LVL2123: 
     testl %ecx, %ecx 
     jle  .L2680 
     movslq %ecx,%rax 
     .loc 2 4882 0 
     testl %r15d, %r15d 
     .loc 2 4880 0 
     leaq (%rax,%rax,4), %rax 
     leaq -40(%rdx,%rax,8), %rdx 
     movq %rdx, 64(%rsp) 

ma non riuscivo a capire come interpretare le etichette come .LVL2123 e direttive come .loc 2 4863 0

Nota Poiché le risposte raffigurati, attraverso la lettura la fonte dell'assemblaggio e la determinazione intuitiva del modello in base ai simboli (come le chiamate di funzione, i rami, l'istruzione di ritorno) è ciò che generalmente faccio. Non sto negando che non funzioni, ma quando una funzione è abbastanza complicata, leggere le pagine di Assembly Listing è un problema e spesso si finisce con l'elencazione che raramente si combina o perché le funzioni di allineamento o ottimizzazione sono semplicemente sballottate il codice a piacere. Ho la sensazione di vedere quanto efficientemente Valgrind gestisce i binari ottimizzati e come in Windows WinDBG sia possibile gestire i binari ottimizzati, c'è qualcosa che mi manca. Quindi, anche se vorrei iniziare con l'output del compilatore e usarlo per correlare. Se il mio compilatore è responsabile per la manipolazione del file binario sarebbe la persona migliore per dire come correlare con la fonte, ma sfortunatamente è stato meno utile e lo .loc è davvero fuorviante. Sfortunatamente spesso devo leggere i dump non riproducibili su varie piattaforme e il minimo tempo che trascorro è nel debug di Windows Mini-dump attraverso WinDBG e un tempo considerevole nel debug di Linux Coredumps. Per quanto ciò possa essere, non sto facendo le cose correttamente, quindi mi è venuta questa domanda.

Answer 1

E 'possibile fare una corrispondenza uno-a-uno con la fonte?

A: no, a meno che l'ottimizzazione non sia disabilitata. Il compilatore può emettere inizialmente un gruppo di istruzioni (o cose simili a istruzioni) per linea, ma l'ottimizzatore quindi riordina, divide, fonde e generalmente le cambia completamente.

---

Se sto smontando il codice di rilascio, osservo le istruzioni che dovrebbero avere una chiara relazione logica con il codice. Ad esempio,

.LBB7924: 
     .loc 2 4880 0 
     testq %rdx, %rdx 
     je  .L2680 

si presenta come un ramo se %rdx è zero, e viene dalla linea 4880. trovare la linea, identificare la variabile in fase di test, fare una nota che è attualmente assegnato a %rdx.

.LVL2123: 
     testl %ecx, %ecx 
     jle  .L2680 

OK, quindi questo test e il ramo ha lo stesso obiettivo, quindi qualunque cosa viene dopo conosce %rdx e %ecx sono entrambi diverso da zero. Il codice originale potrebbe essere strutturato come:

if (a && b) { 

o forse era:

if (!a || !b) { 

e l'ottimizzatore riordinato i due rami ...

Ora hai qualche struttura è possibile si spera che corrisponda al codice originale, è anche possibile capire i compiti del registro. Ad esempio, se si sa che la cosa testata è il membro dati di una certa struttura, leggere all'indietro per vedere dove è stato caricato %rdx dalla memoria: è stato caricato da un offset fisso in qualche altro registro? Se è così, quel registro è probabilmente l'indirizzo dell'oggetto.

Buona fortuna!

Answer 2

La direttiva .loc è ciò che stai cercando. Questi indicano la riga 4863, 4880, ecc. Non esiste una mappatura perfetta tra sorgente e assemblatore ottimizzato (motivo per cui si vede 4880 più di una volta). Ma .loc è come sapere dove si trova nel file. La sintassi è:

.loc <file> <line> <column> 

Answer 3

Se non si collega staticamente alle librerie di sistema, anche senza i simboli di debug ci saranno nomi simbolici nel binario, quello delle funzioni della libreria di sistema collegate.

Questi possono spesso aiutare a restringere il punto in cui ci si trova nel codice. Per esempio, se vedi che nella funzione foo() chiama open() e poi ioctl() e poi si blocca proprio prima di chiamare read(), puoi probabilmente trovare quel punto nella sorgente di foo abbastanza facilmente. (In questo caso potresti anche non aver bisogno del dump - on linux puoi ottenere il record di occorrenza di crash relativo alle funzioni di libreria e di sistema usando ltrace o strace)

Nota che in alcuni formati binari, tuttavia, potrebbe esserci un riferimento indiretto alle funzioni di libreria tramite piccoli wrapper in altre parti del binario. Spesso un dump avrà ancora informazioni sul nome simbolico rilevanti all'indirizzo dell'invocazione nel flusso del programma. Ma anche se no, puoi riconoscere quei wrapper di linkage esterni dal loro range di indirizzi nel binario, e quando ne vedi uno puoi andare a trovare il suo codice e capire a quale funzione esterna si collega.

Ma, come altri hanno detto, se hai il codice sorgente e il sistema in cui si blocca una frequenza tale da essere utile, la soluzione più veloce di solito è di ricostruire con i simboli di debug, o inserire l'output di registrazione e ottenere un crash più utile disco.