ltrace: Impossibile trovare .dynsym o .dynstr in "library.so"

Question

Ho provato a utilizzare il ltrace. Ho provato a utilizzare il seguente comando per profilare il file library.so utilizzato da un programma sampleapp, ltrace -c -T --library=library.so --output=out.txt ./SampleApp. Ma mostra l'errore sopra. Ma library.so è una build di debug. Quindi la tabella dei simboli dovrebbe essere lì. Ho provato a verificarlo con objdump --source library.so | grep CreateSocket(). Restituisce i codici che utilizzano la funzione CreateSocket(). Il che significa che contiene una tabella dei simboli. Perché questo errore si verifica?

Post correlati: measure CPU usage per second of a dynamically linked library

Answer 1

Dipende da come l'eseguibile SampleApp è stato creato. Vedrai quell'errore se fosse collegato staticamente. ltrace funziona solo per applicazioni collegate dinamicamente.

È possibile eseguire ldd SampleApp per mostrare le dipendenze dell'oggetto condiviso. E 'stato in modo dinamico legato e ha una dipendenza a libc, l'uscita del ldd conterrà una linea come questa:

libc.so.6 => /usr/lib/libc.so.6 (0x00007fb24ac53000) 

In tal caso, è possibile utilizzare l'opzione ltrace --library=libc.so.6 e dovrebbe funzionare. Tuttavia, --library=libc.so non corrisponderà (non si otterrà un errore, ma nessuna chiamata alla libreria sarà abbinata).

Quando collegata in modo statico, ldd SampleApp sarà invece mostrano questa uscita:

not a dynamic executable 

mia ipotesi che è a causa di collegamento statico potrebbe essere sbagliato. Il punto importante, tuttavia, è che se ltrace mostra questo errore, devi avviare la diagnosi sul file eseguibile stesso (il file binario) e come è stato creato (opzioni linker), non nella libreria condivisa.

La domanda How does ltrace (library tracing tool) work? ha alcuni buoni riferimenti per comprendere meglio gli interni del ltrace.