Errore "Nessuna fonte disponibile per main()" durante il debug di C++ semplice in Eclipse con gdb

Question

Ho problemi a eseguire il debug di un programma C++ in Eclipse (l'ultimo RC di Helios, aggiornato con l'ultimo CDT da se stesso) su OSX.

Il programma è molto semplice (esenzialmente la Lezione 2 delle esercitazioni OpenGL di NeHe), costituito da un file cpp e, utilizzando i framework OpenGL e Cocoa, e il collegamento con libSDL.a e libSDLmain.a.

La struttura del progetto è molto semplice: i file di origine si trovano in una sottodirectory del progetto chiamata src/e l'eseguibile è incorporato nella directory radice del progetto.

Il problema è che ogni volta che provo ad aggiungere punti di interruzione e debugarlo, i punti di interruzione sembrano essere colpiti perfettamente ma non viene visualizzata alcuna sorgente - invece ottengo solo un errore "Nessuna fonte disponibile per main()" nella finestra del codice .

I flag del compilatore hanno ottimizzazioni impostate su none e sia il compilatore che il linker hanno il flag di simboli di debug impostato (-g).

L'impostazione di debug in Eclipse è impostata su "Progredire spawn standard" e il debugger è impostato su "gdb".

Ora la cosa più strana è che se provo a eseguire il debug dell'eseguibile stesso esatto - vale a dire. la stessa identica che è stata costruita da Eclipse - usando gdb dal Terminale (shell) allora tutto funziona bene. I punti di interruzione vengono colpiti, viene visualizzato il codice sorgente, nessun problema.

Mi sono assicurato che sia Eclipse che la shell stiano utilizzando lo stesso eseguibile gdb, e lo sono (è/usr/bin/gdb).

Ora posso sbagliarmi, ma tutto questo mi fa pensare che non ci può essere un problema con il compilatore e linker bandiere (perché lo stesso eseguibile è possibile eseguire il debug dalla shell), quindi presumibilmente il problema deve essere con il modo gdb viene invocato da Eclipse? Forse quando eseguito da Eclipse gdb sta rilevando diversi file di configurazione o qualcosa di diverso rispetto a quando viene eseguito dalla shell? (Qualcuno lo sa?)

Apprezzerei molto qualsiasi aiuto con questo perché mi sta facendo girare lentamente!

Per favore fatemi sapere se ci sono altri dettagli che potrebbero essere utili - numeri di versione esatta di Eclipse/CDT/gdb, linker esatto/righe di comando del compilatore, ecc - e io aggiornare molto volentieri questo post con loro .

Molte grazie in anticipo,

thoughton.

--- a cura @ "14 ore fa" ---

ho provato il "aggiungi percorso file system" (con "cercare sottocartelle") l'opzione, ma che non ha funzionato . Ho anche provato a creare un nuovo progetto completamente piatto, ma anche questo non ha funzionato. Ho anche provato ad ottenere una versione Galileo (eclipse-SDK-3.5.2RC4 con aggiornamento CDT), ma ciò non ha fatto differenza (a parte il fatto che gdb è più lento da avviare).

Ed ecco un'altra cosa strana che ho notato: una volta che ottengo il messaggio "No sorgente disponibile", se poi switch di console di Eclipse per visualizzare la console "gdb", e girare anche su "modalità console Verbose" in modo da poter comunicare Posso quindi inviare comandi "l" e "bt" e farli funzionare correttamente, mostrando la sorgente e lo stack corretti in cui è stato colpito il mio punto di interruzione.Che, correggimi se sbaglio, deve significare che le informazioni sono lì e che gdb viene invocato correttamente, quindi perché Eclipse non vedrà queste informazioni?

Mi sto avvicinando a rinunciare a Eclipse, ad essere sincero ... Sono arrivato anche ad essa con così tante speranze.

Qualsiasi ulteriore aiuto o pensiero sarebbe molto apprezzato.

t.

Answer 1

ho trovato la risposta! Ed è imbarazzantemente semplice.

Il problema era che stavo usando la versione Release di SDL invece della versione Debug! (Avevo 'libsdl' da MacPorts mentre avrei dovuto avere 'libsdl-devel'.)

Quindi la mia risposta generica è: assicurati che le librerie che stai collegando siano state compilate con i flag di debug impostati, non è sempre basta assicurarsi che il proprio codice li abbia impostati.

Answer 2

This thread suggerisce:

-g -O0 

per flag di debug da impostare per la compilazione Eclipse CDT.
A volte, è semplice un problema di ricostruire completamente l'applicazione (like here)

Vedi anche this thread che descrive una situazione simile:

I have noticed that sometimes in Eclipse I have to go and specifically add the path to my source files using the " add filesystem path " (with " search sub-folders ") in the Debug Dialog (even when they are in the same project I am debugging), but I have not noticed a pattern to when I have to do this. But it may be worth a try.

Answer 3

Per chiunque altro che si possono verificare questo problema,

ho installato il linuxtools/valgrind plugin di ieri sera per fare un po 'di memoria profiling, e sembra che questo ha rotto il gdb normale. quando ho rimosso i plugin linuxtools, tutto ha ripreso a funzionare normalmente.

Quindi potresti provare.

Answer 4

Questo problema dipende dalla modalità di chiamata di gdb. Ho trovato che avevo bisogno di specificare manualmente i percorsi dei file di origine quando ho ricevuto quell'errore. Anche se l'avevo già configurato sotto le proprietà del progetto. Dopo averlo fatto, Eclipse non ha più avuto problemi a fornire la fonte appropriata.

L'utilizzo della versione contro la versione di debug di una libreria può essere il problema specifico (se si stava creando una libreria dal sorgente, quindi eseguendo il debugging). Se qualcuno sta utilizzando una libreria precompilata, non sarà mai in grado di impostare punti di interruzione al suo interno e quindi quella correzione non si applicherebbe a loro.

Answer 5

Passare a Proprietà progetto, C/C++ Build -> Impostazioni. Nella prima scheda (Impostazioni strumento) in Cross GCC Compiler, fare clic su Debug e impostare Debug Level su Maximum (-g3)

Answer 6

Ho riscontrato questo problema quando ho compilato l'ultimo gcc, ma non ho aggiornato il gdb più recente. Dopo l'aggiornamento, ha funzionato correttamente.

Answer 7

Ecco un'altra ragione per questo problema. La mia configurazione utilizzava -g3 come opzione per gcc. Cambiarlo per -g ha risolto il problema. Sembra esserci qualche incompatibilità tra gcc e gdb. Ho controllato che gdb era l'ultima versione (usando apt-get).

Answer 8

Vorrei aggiungere un po 'di sangue a questo vecchio thread.

Ho riscontrato questo problema quando ho provato a compilare e eseguire il debug di un progetto di braccio di GNU.

ho risolto il problema modificando il Makefile: aggiungendo "-O0 -g" alla fine di questa linea "CFLAGS + = -Wall -Werror -O3"

Answer 9

Ho avuto un problema simile. Stavo usando CFLAGS=-Wall -O2 -fPIC -DPIC -lm -lasound e mai avuto problemi a compilarlo, ma quando ho provato a debbug su Eclipse IDE ottengo questo errore: No source available for "main() at 0x401080" poi ho aggiunto -g a questa linea e ha funzionato bene:

CFLAGS=-g -Wall -O2 -fPIC -DPIC -lm -lasound

Answer 10

pensato di parlare, che nel caso in cui si sta utilizzando cMake per generare il progetto, un approccio per la soluzione sarà quella di aggiungere la "bandiera di debug" al comando cMake, vale a dire -

$ cmake/path/to/main/cmake_file - DCMAKE_BUILD_TYPE=Debug