[C] debugger, come?

[noodles83]

Devo debuggare un progaramma scritto in c composto da diversi file.c header.h

Ho due domande:
1) come è possibile debuggare tramite shell in linux?

2) in seguito a un problema mi è stato consigliato anche di fare un esecuzione passo-passo... che significa? come è possibile farla?

[71104]

Originariamente inviato da noodles83

Ho due domande:
1) come è possibile debuggare tramite shell in linux?

la shell non è mica un debugger

il debugger solitamente incluso in qualsiasi distro di Linux è gdb (il debugger della collezione GNU), ma usarlo così da linea di comando è come martellarsi i coglioni con una mazzetta da 3,5 kg scaldata sul fuoco.

usa un IDE
se usi KDE dovrebbe esserci KDevelop

[andbin]

Originariamente inviato da 71104

il debugger solitamente incluso in qualsiasi distro di Linux è gdb (il debugger della collezione GNU), ma usarlo così da linea di comando è come martellarsi i coglioni con una mazzetta da 3,5 kg scaldata sul fuoco.

Garantisco personalmente che usare il gdb non è così "traumatico"! Una volta che ci hai fatto la mano e imparato i principali comandi vai che è un piacere. Non sto scherzando (e non è un pesce d'aprile).

[noodles83]

Originariamente inviato da 71104

la shell non è mica un debugger

il debugger solitamente incluso in qualsiasi distro di Linux è gdb (il debugger della collezione GNU), ma usarlo così da linea di comando è come martellarsi i coglioni con una mazzetta da 3,5 kg scaldata sul fuoco.

usa un IDE
se usi KDE dovrebbe esserci KDevelop

uso ubuntu con gnome... esiste qualche debugger con interfaccia grafica?

[71104]

Originariamente inviato da andbin

Garantisco personalmente che usare il gdb non è così "traumatico"! Una volta che ci hai fatto la mano e imparato i principali comandi vai che è un piacere. Non sto scherzando (e non è un pesce d'aprile).

ma si, alla fine è così, ti impari a memoria quelle 4 o 5 lettere che costituiscono i comandi principali, sbagli le prime volte facendo Step Over anziché Step Into, poi ti ci abitui e vai spedito. ma vuoi mettere quei bei pulsanti colorati?

e non scherzo nemmeno io: a conti fatti la curva d'apprendimento per l'uso di un debugger grafico ben fatto è pressoché orizzontale, passi il mouse su un bottone, attendi che appaia il tooltip e intuisci immediatamente due cose:
1) a cosa serve il bottone
2) che il debugger ha quella funzionalità che prima neanche conoscevi
e a quel punto ti rendi conto che se prima trovavi produttivo lavorare da linea di comando era solo perché non avevi ancora sperimentato la GUI, e non torneresti più indietro.

solito discorso che vale in generale per qualsiasi strumento CUI che abbia una controparte GUI

[71104]

Originariamente inviato da noodles83

uso ubuntu con gnome... esiste qualche debugger con interfaccia grafica?

purtroppo non ti so aiutare, le rare volte che ho usato Linux nella mia vita è stato per necessità e ho fatto a meno del debugger ^^

[Pica!]

Prova Scite...

[cionci]

Insight lo trovi nei repository ubuntu.
E' un ottimo frontend per gdb, ovviamente devi compilare passando il parametro: -ggdb

[recoil]

Originariamente inviato da andbin

Garantisco personalmente che usare il gdb non è così "traumatico"! Una volta che ci hai fatto la mano e imparato i principali comandi vai che è un piacere. Non sto scherzando (e non è un pesce d'aprile).

confermo
per quanto mi riguarda uso solo valgrind (UTILISSIMO) e gdb. poi fprintf a manetta per loggare tutto il loggabile.
secondo me è meglio abituarsi a debuggare senza tanti "fronzoli". ci sono situazioni nelle quali non puoi nemmeno eseguire il codice passo passo, ad esempio quando la tua applicazione comunica (via modem, rete ecc.) con altre. sarà anche più scomodo ma è un metodo che funziona sempre.
71104 dici giustamente che quando provi la GUI poi è dura tornare indietro. motivo in più per non diventare schiavi della GUI, perché quando non puoi proprio usarla poi sono seccature

[noodles83]

grazie per le risposte ragazzi!

vorrei chiedere un altra cosa...

per debuggare che opzioni devo dare al compilatore?

[cionci]

-ggdb

[noodles83]

PROBLEMA!!

se compilo normalmente con gcc -o file file.c ....etc... tutto va bene e compila correttamente.

se invece compilo con gcc -o -ggdb file file.c ...etc... mi spunta fuori questo:

paolo@paolo-linux:~/programmazione/LCS/lcschat$ gcc -o -ggdb client client.c lcscom.c -L./lib -lpthread -lncurses -lMainWindow
client.rodata+0x0): multiple definition of `_fp_hw'
/usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../lib/crt1.o:../sysdeps/i386/elf/start.S:65: first defined here
client: In function `__data_start': multiple definition of `__dso_handle'
/usr/lib/gcc/i486-linux-gnu/4.0.3/crtbegin.o.data+0x0): first defined here
client: In function `_init':/build/buildd/glibc-2.3.6/build-tree/i386-libc/csu/crti.S:32: multiple definition of `_init'
/usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../lib/crti.o:/build/buildd/glibc-2.3.6/build-tree/i386-libc/csu/crti.S:11: first defined here
client: In function `_start':../sysdeps/i386/elf/start.S:65: multiple definition of `_start'
/usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../lib/crt1.o:../sysdeps/i386/elf/start.S:65: first defined here
client: In function `_fini':/build/buildd/glibc-2.3.6/build-tree/i386-libc/csu/crti.S:47: multiple definition of `_fini'
/usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../lib/crti.o:/build/buildd/glibc-2.3.6/build-tree/i386-libc/csu/crti.S:11: first defined here
client: In function `__i686.get_pc_thunk.bx':/build/buildd/glibc-2.3.6/build-tree/i386-libc/csu/crtn.S:34: multiple definition of `__i686.get_pc_thunk.bx'
/usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../lib/crti.o:/build/buildd/glibc-2.3.6/build-tree/i386-libc/csu/crti.S:11: first defined here
client.rodata+0x4): multiple definition of `_IO_stdin_used'
/usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../lib/crt1.o:../sysdeps/i386/elf/start.S:71: first defined here
client: In function `__data_start': multiple definition of `__data_start'
/usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../lib/crt1.o:../sysdeps/i386/elf/start.S:65: first defined here
/tmp/ccOHaJrV.o: In function `ResizeHandler':client.c.text+0x0): multiple definition of `ResizeHandler'
client: first defined here
/tmp/ccOHaJrV.o: In function `SigIntHandler':client.c.text+0x15): multiple definition of `SigIntHandler'
client: first defined here
/tmp/ccOHaJrV.o: In function `gestInput':client.c.text+0xff): multiple definition of `gestInput'
client: first defined here
/tmp/ccOHaJrV.o: In function `main':client.c.text+0x499): multiple definition of `main'
client: first defined here
/tmp/cc7Ngxv1.o: In function `createServerChannel':lcscom.c.text+0x0): multiple definition of `createServerChannel'
client: first defined here
/tmp/cc7Ngxv1.o: In function `destroyServer':lcscom.c.text+0xf2): multiple definition of `destroyServer'
client: first defined here
/tmp/cc7Ngxv1.o: In function `acceptConnection':lcscom.c.text+0x105): multiple definition of `acceptConnection'
client: first defined here
/tmp/cc7Ngxv1.o: In function `receiveMessage':lcscom.c.text+0x12e): multiple definition of `receiveMessage'
client: first defined here
/tmp/cc7Ngxv1.o: In function `sendMessage':lcscom.c.text+0x252): multiple definition of `sendMessage'
client: first defined here
/tmp/cc7Ngxv1.o: In function `closeConnection':lcscom.c.text+0x32f): multiple definition of `closeConnection'
client: first defined here
/tmp/cc7Ngxv1.o: In function `openConnection':lcscom.c.text+0x342): multiple definition of `openConnection'
client: first defined here
collect2: ld returned 1 exit status
paolo@paolo-linux:~/programmazione/LCS/lcschat$

[cionci]

gcc -ggdb -o file file.c

-o deve essere seguito dal nome del file eseguibile

[andbin]

Originariamente inviato da noodles83

se invece compilo con gcc -o -ggdb file file.c ...etc...

L'opzione -o output non la devi "spezzare" mettendo in mezzo qualcos'altro!!!!

gcc -ggdb -o file ........

[noodles83]

ehehe... avete troppo ragione! scusate, ma sto imparando ora...

[RaouL_BennetH]

per gnome (ma non solo) si sposa bene visto che è in gtk l'ide anjuta.

[71104]

Originariamente inviato da recoil

71104 dici giustamente che quando provi la GUI poi è dura tornare indietro. motivo in più per non diventare schiavi della GUI, perché quando non puoi proprio usarla poi sono seccature

si recoil, lo so che questo post l'hai scritto con una sessione telnet