gdbを使用してEclipseで単純なC ++をデバッグすると、「main（）に使用できるソースがありません」エラー
OSXのEclipse（それ自体から最新のCDTで更新されたHeliosの最新のRC）でC++プログラムをデバッグするのに問題があります。
プログラムは非常にシンプルで（本質的には、NeHeのOpenGLチュートリアルのレッスン2）、1つのcppファイルで構成され、OpenGLおよびCocoaフレームワークを使用し、libSDL.aおよびlibSDLmain.aとリンクします。
プロジェクトの構造は非常に単純です。ソースファイルはsrc /というプロジェクトのサブディレクトリにあり、実行可能ファイルはプロジェクトのルートディレクトリにビルドされます。
問題は、ブレークポイントを追加してデバッグしようとすると、ブレークポイントが完全にヒットしたように見えても、ソースが表示されないことです。代わりに、コードウィンドウに「main（）で使用できるソースがありません」というエラーが表示されます。
コンパイラフラグは最適化がnoneに設定されており、コンパイラとリンカーの両方にデバッグシンボルフラグが設定されています（-g）。
Eclipseのデバッグ設定は「Standard spawn progess」に設定され、デバッガーは「gdb」に設定されています。
今、最も奇妙なことは、まったく同じ実行可能ファイルをデバッグしようとした場合です。 Eclipseによってビルドされたものとまったく同じ-ターミナル（シェル）からgdbを使用すると、すべてが正常に動作します。ブレークポイントがヒットし、ソースコードが表示されますが、まったく問題はありません。
Eclipseとシェルの両方が同じgdb実行可能ファイルを使用していることを確認しました（それらは/ usr/bin/gdbです）。
今私は間違っているかもしれませんが、これはすべてコンパイラとリンカーのフラグに問題がないことを示唆しています（同じ実行可能ファイルがシェルからデバッグ可能であるため）、おそらく問題はgdbの呼び出し方法にあるはずですEclipse内から？おそらく、Eclipse gdbから実行すると、シェルから実行した場合とは異なる構成ファイルなどを取得しますか？ （誰でも知っていますか？）
これはゆっくりと私をルーピーにしてくれるので、私はこれでどんな助けでも本当に感謝します！
役立つと思われるその他の詳細-Eclipse/cdt/gdbの正確なバージョン番号、正確なリンカー/コンパイラーのコマンドラインなど-があれば教えてください。この投稿を喜んで更新します。
よろしくお願いいたします。
思想。
--- edited @ "14 hours ago" ---
「ファイルシステムパスの追加」（「サブフォルダの検索」を使用）オプションを試しましたが、機能しませんでした。また、完全にフラットなプロジェクトを新たに作成しようとしましたが、それもうまくいきませんでした。私はGalileoリリース（Eclipse-SDK-3.5.2RC4とCDT更新）を入手することも試みましたが、違いはありません（gdbの起動が遅いことを除いて）。
そして、ここで私が気付いた奇妙な何かがあります：「No source available」メッセージが表示されたら、Eclipseのコンソールを切り替えて「gdb」コンソールを表示し、「Verbose console mode」をオンにして通信できるようにすると、次に、「l」および「bt」コマンドを発行し、それらを正常に動作させて、ブレークポイントがヒットした正しいソースとスタックを表示します。これは、私が間違っている場合は訂正してください。情報が存在し、gdbが正しく呼び出されていることを意味する必要があります。なぜEclipseはこの情報を表示しないのですか？
正直言ってEclipseをあきらめようとしています...そんな大きな希望を持ってやって来ました。
追加の助けや考えは非常に高く評価されます。
t。
答えを見つけた！そして、それは恥ずかしいほど簡単です。
問題は、デバッグバージョンではなくリリースバージョンのSDLを使用していたことです。 （MacPortsから「libsdl」があったのに対して、「libsdl-devel」があったはずです。）
だから私の一般的な答えは：リンクしているライブラリがデバッグフラグも設定してコンパイルされていることを確認してください。自分のコードに設定されていることを確認するだけでは必ずしも十分ではありません。
このスレッド は次のことを示唆しています。
-g -O0
デバッグフラグをEclipse CDTコンパイル用に設定します。
たまに、アプリケーションを完全に再構築するという単純な問題があります（ ここのように ）
同様の状況を説明する this thread も参照してください。
私はEclipseで、デバッグダイアログの「
add filesystem path」（「search sub-folders」付き）を使用してソースファイルへのパスを追加しなければならない場合があることに気付きました（たとえそれらが私がデバッグしているのと同じプロジェクト）、しかしこれをしなければならないときのパターンに気づきませんでした。しかし、試してみる価値があるかもしれません。
この問題のもう1つの理由は次のとおりです。私の構成では、gccのオプションとして-g3を使用しました。これを-gに変更すると、問題が解決しました。 gccとgdbの間には互換性がないようです。 gdbが最新のリビジョンであることを確認しました（apt-getを使用）。
この古い糸に少し新しい血を加えたいと思います。
この問題は、gnu armプロジェクトをコンパイルしてデバッグしようとしたときに発生しました。
Makefileを変更して問題を解決しました。この行の最後に "-g -O0"を追加します "CFLAGS + = -Wall -Werror -O3"
プロジェクトのプロパティ、C/C++ビルド->設定に移動します。 Cross GCC Compilerの最初のタブ（Tool Settings）で、Debuggingをクリックし、Debug LevelをMaximumに設定します（-g3）。
最新のgccをコンパイルしたときにこの問題が発生しましたが、最新のgdbに更新していません。更新後、正常に動作しました。
言うまでもありませんが、プロジェクトをビルドするためにcmakeを使用している場合、解決策の1つのアプローチは、「デバッグフラグ」をcmakeコマンドに追加することです。
$ cmake/path/to/main/cmake_file -DCMAKE_BUILD_TYPE=Debug
この問題が発生する可能性のある他の人のために、
昨夜、linuxtools/valgrindプラグインをインストールしてメモリプロファイリングを行いましたが、これにより通常のgdbが壊れたようです。 linuxtoolsプラグインを削除すると、すべてが再び正常に動作し始めました。
だからあなたはそれを試してみたいかもしれません。
同様の問題がありました。私はCFLAGS=-Wall -O2 -fPIC -DPIC -lm -lasoundを使用しており、コンパイルに問題はありませんでしたが、EclipseでデバッグしようとするとIDEこのエラーが発生しました：No source available for "main() at 0x401080"次に、この行に-gを追加し、うまくいきました：
CFLAGS = -g -Wall -O2 -fPIC -DPIC -lm -lasound
この問題は、gdbの起動方法によって異なります。そのエラーが発生したとき、ソースファイルの場所を手動で指定する必要があることがわかりました。プロジェクトのプロパティですでに構成済みですが。そうした後、Eclipseは適切なソースを提供するのに問題がなくなりました。
ライブラリのリリースバージョンとデバッグバージョンの使用は、特定の問題である可能性があります（ソースからライブラリをビルドしてからデバッグする場合）。誰かがプリコンパイル済みライブラリを使用している場合、そのライブラリ内にブレークポイントを設定することはできないため、修正はそれらに適用されません。
同じ問題に一度遭遇した。 Altキーを押しながらEntrキーを押すか、プロジェクトを右クリックしてプロジェクトのプロパティに移動し、下部を下にスクロールすると、プロパティが表示されます。左側のC/C++ビルドを展開します。次に、設定をクリックします。設定を開いたら、ツール設定をクリックします。 MCU GCCコンパイラには、デバッグオプションがあります。デバッグをクリックして追加
-g -O0
その他のデバッグフラグ。今すぐプロジェクトをデバッグしてみてください。
このメッセージは表示する理由がたくさんあるようです。
私にとって（マイクロコントローラーのデバッグのコンテキストでは）リンク時の最適化でした。 -flto壊れました。削除-flto「その他のオプション」フィールドから、これを修正しました。
Eclipse Neon（4.6）では、プロジェクト->プロパティ-> C/C++ビルド->設定->ツール設定-> Cコンパイラ->その他->その他のオプションを参照してください。
私はこの問題に直面しました。しばらくしてから、[デバッグの構成]ダイアログの[引数]と[メイン]タブが競合していることに気付きました。
C/C++アプリケーションとプログラムの引数が同じバイナリファイルを指していることを確認します。