Eseguibile core dump da solo?

Question

La pagina di Wikipedia su Core dump dice

Nei sistemi Unix-like, i core dump in genere utilizzano lo standard eseguibile immagine formato:

a.out in older versions of Unix, 
ELF in modern Linux, System V, Solaris, and BSD systems, 
Mach-O in OS X, etc. 

Significa questo un core dump è eseguibile si? Se no, perché no?

Edit: Dato @ WumpusQ.Wumbley menziona un coredump_filter in un commento, forse la domanda di cui sopra dovrebbe essere: può un core dump essere prodotto in modo che sia eseguibile da solo?

Answer 1

Nel vecchio varianti Unix è stato il default per includere il testo così come i dati nel core dump, ma è stato dato anche nella formato a.out e non ELF. Il comportamento predefinito di oggi (in Linux sicuramente, non sicuro al 100% delle varianti BSD, Solaris, ecc.) È di avere il core dump in formato ELF senza le sezioni di testo, ma questo comportamento può essere modificato.
Tuttavia, un core dump non può essere eseguito direttamente in nessun caso senza alcun aiuto. Il motivo è che ci sono due cose che mancano da un semplice file core. Uno è il punto di ingresso, l'altro è il codice per ripristinare lo stato della CPU allo stato in corrispondenza o appena prima che si verificasse il dumping (di default mancano anche le sezioni di testo).
In AIX c'era un'utilità chiamata undump ma non ho idea di cosa gli sia successo. Non esiste in nessuna distribuzione Linux standard che conosca. Come menzionato sopra (@WumpusQ) c'è anche un tentativo di un progetto simile per Linux menzionato nei commenti precedenti, tuttavia questo progetto non è completo e non ripristina lo stato della CPU allo stato originale. Tuttavia, è ancora abbastanza buono in alcuni casi specifici di debug.
Vale anche la pena ricordare che esistono altri file in formato ELF che non possono essere eseguiti e che non sono file core. Come file oggetto (output del compilatore) e file .so (oggetti condivisi). Quelli richiedono una fase di collegamento prima di essere eseguiti per risolvere gli indirizzi esterni.

Answer 2

Esistono due tipi di core dump: core core dump e core core di processo. Differiscono in molti aspetti, come il modo in cui vengono creati e il metodo utilizzato per analizzarli.

Nella maggior parte dei casi, il segnale che causa l'arresto anomalo dell'applicazione è SIGSEGV (violazione della segmentazione) o SIGBUS.

tipi simili di segnali trigger un core dump .. forse .. invocarlo

Answer 3

Ho contattato questa domanda il creatore del programma di utilità undump per la sua competenza, e ha ottenuto la seguente risposta:

Come menzionato in alcune delle risposte lì, è possibile includere le sezioni di codice impostando the coredump_filter, ma non è il default per Linux (e non sono del tutto sicuro delle varianti BSD e di Solaris). Se le varie sezioni di codice vengono salvate nel core-dump originale , non c'è davvero nulla che non funzioni per creare il nuovo eseguibile . Tuttavia, richiede alcune modifiche nel file principale originale (ad esempio includendo un punto di ingresso e puntando la voce al codice che ripristinerà i registri della CPU). Se il file principale è modificato in questo modo diventerà un eseguibile e potrai eseguire per eseguirlo.Sfortunatamente, alcuni stati non stanno andando a da salvare in modo che il nuovo eseguibile non possa essere eseguito direttamente. Aprire file, socket, pips, ecc non saranno aperti e potrebbero anche puntare su altri FD (che potrebbero causare ogni sorta di cose strane). Tuttavia, sarà probabilmente sufficiente per la maggior parte delle attività di debug che eseguono le piccole funzioni da gdb (in modo che non si ottenga un "non eseguibile di un eseguibile ").

Answer 4

Come altri ragazzi hanno detto, non penso che sia possibile eseguire un file di dump di base senza il file binario originale.

Nel caso siate interessati a eseguire il debug del binario (simboli ed è debug inclusi, in altre parole non è spogliato) allora si può eseguire gdb binary core.

All'interno di gdb è possibile utilizzare il comando bt (backtrace) per ottenere la traccia dello stack quando l'applicazione si arresta in modo anomalo.