GDB reports 'No source file named'... but file exists!

I am on CLion 2018.1 EAP.  The project is imported from a legacy CMakeLists.txt file.  The source tree contained files that share the same name, but only 1 of which should be compiled.  Compile is OK, debug is not.

No source file named [..]/io/parser/script/base/Script.tab.cc.
No source file named [..]/parser/verilog/base/SimplifiedVerilog.tab.hh.
No source file named [..]/io/parser/verilog/base/SimplifiedVerilog.tab.cc.
No source file named [..]/retired/parser/verilog/linux/base/SimplifiedVerilog.tab.cc
No source file named [..]/retired/parser/verilog/linux/base/SimplifiedVerilog.tab.cc

(these files exist)

How can CLion control which directories get passed to GDB?  I have tried to exclude the wrong directories in the GUI. Manually specifying the directory using 'directory' command works.

 

 

 

 

6 comments
Comment actions Permalink

Hi! How are these files added to the project in the CMakeLists.txt file? Are all of them added? To one target or to different targets?

0
Comment actions Permalink

To the best of my knowledge, they were not added to CMakeLists.txt.  I checked the output of the compile and the correct versions of the files are built.

I did an experiment.  I removed the duplicate files from the file system, wiped cmake-build-debug directory, and did a full rebuild.  GDB reported the same error!

I also observed that I placed breakpoints on the wrong version of the files.  This was seen in doing a grep of workspace.xml.

Thus, for the clean build, the only reference to the old files was in workspace.xml (breakpoint section, I think).

0
Comment actions Permalink

Could you please send the project to clion-support at jetbrains.com?

0
Comment actions Permalink

Did you solve this? The same is happening to me.

0
Comment actions Permalink

This error from GDB is misleading, as it is raised when it cannot find the symbols for the file... not that the source file it is reporting back is itself actually missing.

In a particular case of this I was looking at, the problem was resolved by making it so that gdb was being launched in the same directory as the output executable.  So instead of:

    gdb /path/to/exe

...run from some random place, it did...

    cd /path/to
    gdb /path/to/exe

...and that worked.

0

Please sign in to leave a comment.