2012-06-29 19 views
10

Ho usato gdb normalmente per 1 o 2 progetti. Cioè Invoco lo gdb --args prog args. gdb gira nella stessa tty del programma che sto eseguendo il debug.attendere che gdb alleghi

Tuttavia, il mio ultimo progetto è la modifica dell'utilità dtach. Questo è un programma come lo schermo, quindi le tty vengono reindirizzate altrove, quindi devo usare la funzionalità attach di gdb.

Il problema con gdb attach è che ovviamente non è possibile allegare sin dall'inizio poiché è necessario eseguire il programma prima per ottenere un pid a cui collegarsi.

C'è un modo per far sì che un programma attenda fino al punto in cui è allegato gdb?

Non riesco a utilizzare gdbserver come sono su cygwin. Inoltre ho provato a usare pause(), ma questo si è bloccato quando ho provato a continuare.

+0

Il mio male, il messaggio nella mailing list lamentando che gdbserver non funziona su Cygwin era di 9 anni fa. Lo ha compilato ieri sera e funziona bene. Per qualche ragione il binario gdbserver non è incluso nel repository cygwin, probabilmente a causa degli stretti casi d'uso su cygwin. C'è anche un modo potenziale per collegare gdb in programma dall'inizio usando lo stub di debugging gdb. Grazie comunque per le risposte. – rhlee

risposta

1

Alcune piattaforme possono avere istruzioni o trap di attesa per il debugger.

Più facilmente, è possibile fare in modo che il programma attenda alcune condizioni esterne, come una connessione a un socket o la scrittura di alcuni dati in un fifo. È quindi possibile effettuare la connessione o inviare dati fittizi da un terzo terminale.

Oppure è possibile inserire un ciclo infinito nel programma, testando il valore di alcune variabili volatili che si modificheranno con il debugger per consentirne il proseguimento.

Se ricordo che è possibile utilizzare apis di Windows nei programmi Cygwin, e alcune ricerche sul Web sembrano indicare uno per rilevare se il programma è in fase di debug, quindi è possibile eseguire il loop fino a quando non viene restituito.

12

Ecco come risolvo questo problema. Ho visto anche altre persone fare questo trucco.

Scegliere un punto in cui si desidera interrompere il programma e attendere che si colleghi il debugger. Per la maggior parte dei programmi, questo sarà l'inizio, ma se c'è qualche lavoro di init che devi fare potresti voler finire e poi farlo.

Put in un ciclo simile a questo:

#ifdef DEBUG 

int i = 0; 

while (i == 0) 
{ 
    usleep(100000); // sleep for 0.1 seconds 
} 

#endif // DEBUG 

Una volta collegato con successo al processo, è possibile utilizzare il debugger per modificare il valore della variabile i, che romperà il ciclo e consentire il normale esecuzione per continuare.

Il comando gdb per cambiare la variabile di 1: set var i = 1

Un'altra cosa che faccio tutto il tempo: mi definisco una breve funzione chiamata nop() che non fa nulla ("nessuna operazione"). Quindi inserisco una chiamata allo nop() in qualsiasi posto che voglio interrompere e inserire un punto di interruzione all'interno di nop().

Nota: se si compilano i build di debug con -O0, il compilatore non ottimizzerà la variabile. Se avevi bisogno di questo trucco per lavorare con una build ottimizzata, suppongo che avresti bisogno di dichiarare la variabile come volatile.

+0

Ci deve essere una soluzione in cui si installa un gestore di segnale che imposterà la variabile 'i' per interrompere il ciclo? – To1ne

9

Almeno con LLDB rendendo il processo inviare SIGSTOP a se stesso dovrebbe fare il trucco. Il comando di debugger continue emetterà quindi lo SIGCONT. Questo dovrebbe funzionare anche con GDB. In alternativa, prova SIGINT anziché SIGSTOP.

Includi intestazione

#include <signal.h> 
#include <csignal> // or C++ style alternative 

poi

raise(SIGSTOP) 
+0

Il comando gdb 'segnali informativi' stampa l'elenco dei segnali e che siano o meno passati al programma. È quindi possibile modificare il suo comportamento con il comando 'handle'. –

Problemi correlati