I have the following Eclipse CDT setup on a Red Hat Linux system:
Eclipse Mars with CDT 8.7
gdb 7.6
I have two projects open in my workspace
Project1: the main source code that builds the executable I want to debug
Project2: library code that gets statically linked with the binary in Project1
Project2 is linked to Project1 in its properties.
The problem occurs when I try to set breakpoints in a debug session in source files that are in Project2. gdb reports the following error:
No source file named <absolute_path_to_file>.
The weird thing is that I can set breakpoints in the gdb console in Eclipse using the function name and/or function name and line number syntax. When I do this, gdb reports that it successfully set the breakpoint showing the file and line number. The file name, in the trace message, has no path (maybe relevant?)
Using objdump I was able to confirm that my executable has all of the symbols and files in it (not absolute paths though... relevant?)
Once I get the debugger to stop at the breakpoint after setting it using the function name, I can then add/remove breakpoints within the Debug perspective like normal; even if I restart the debugging session.
I've seen lots of comments about loading shared libraries into gdb, but the code I'm trying to break into is in a statically linked library, not a shared one.
Given that I can add breakpoints using the normal method once I get gdb to break on one added manually in the conosole, indicates to me that maybe something is missing in my gdb settings.
Any thoughts?
Thanks!
Related
I'm trying to debug an application compiled with Ninja.
I have my source code /usr/local/...project-src/
I have my build output located at /usr/local/...project-src/out/Debug/build
The compiled output includes debug information
file out/Debug/build includes:
ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, with debug_info, not stripped
I'm able to add breakpoints when using relative paths:
cd /usr/local/...project-src
gdb
file out/Debug/build
b x/y.cc:34
# success
Breakpoint 1 at <mem-loc>: file ../../x/y.cc, line 34.
But when I use absolute paths, it fails
cd /usr/local/...project-src
gdb
file out/Debug/build
b /usr/local/...project-src/x/y.cc
# failure
No source file named /usr/local/...project/x/y.cc.
info source prints No current source file.
dir prints Source directories searched: /usr/local/...project-src/out/Debug:$cdir:$cwd
I've also tried:
b ../../x/y.cc, I tried this since that's what the successful command outputs. Surprisingly, it didn't work which is really confusing me.
running gdb from the root directory and other directories.
doing cd to various directories after starting gdb
messing around with set substitute-path and adding directories using dir
I'm hoping the solution is simple, since breakpoints, and variable values, and everything else works, just not with absolute paths.
Also worth noting, once I've successfully added a breakpoint to a file (using the relative path), the other paths also work (both the absolute path and the ../../x/y.cc path).
Lastly, as to why I want absolute paths to work, I'm using CLion's remote-gdb configuration to connect to a gdbserver, and CLion is using absolute paths for whatever reason. Perhaps there is a way to configure CLion to just use the x/y.cc instead? I'm running the gdbserver with gdbserver :2000 out/Debug/build and configured CLion's target remote, symbol file, and sysroot. I've also tried setting the path mappings in CLion.
Edit, testing on a dummy HelloWorld project using g++ -g instead of ninja to build, I'm able to add breakpoints using absolute paths e.g. b /usr/local/...untitled/main.cpp:4. So it seems to be, for some reason, gdb supports full paths for the HelloWorld project built with g++, but not for the real project built with Ninja.
tldr, resolved using gdb --readnow.
Per the comment suggestion I began digging into my build config. 2 things I noticed:
1) The issue disappeared if I built with less debug details. But then I wouldn't be able to inspect expressions & variables. So I thought the issue may somehow related to gdb not having enough memory or cache to load all the debug info. This sounds reasonable since the project source code contains 100,000's of files.
2) As I mentioned earlier, I could add breakpoints using absolute paths after I had added a breakpoint using a relative path to the same file.
I learnt of the info, info set, and info sources commands. Although the outputs were the same between the light-weight debug build and the full debug built (step 1), I noticed that the output of info sources changed in step 2. Before I had added the breakpoint using a relative path, `info sources would list all source files under 'Source files for which symbols will be read in on demand'. But after adding a relative breakpoint, a few of the files (I think the files on the current frame) would be added to the loaded source files.
So I went looking for a way to tell gdb to load all the source files and discovered the gdb --readnow flag (or file <built-file> -readnow with 1 dash -) and though it prints a bunch of warning messages, it seems to resolve my issue.
That being said, I never discovered how to configure CLion to use the readnow flag. The newest EAP (2019.3) release supposedly supports configuring .gdbinit files individual per project, though I haven't tried this. I also don't know if readnow can be configured in a .gdbinit file since it's not a setting. I kind of circumvented the entire configuring CLion issue when I figured how to correctly configure custom build targets and applications in CLion during this investigation.
Edit,
Yet another workaround. If I cd into /usr/local/...project-src/out/Debug which contains the build file (as opposed to /usr/local/...project-src/), then absolute paths work even without readnow.
My workspaces are located in my home directory.
I am currently trying to debug python code which loads a shared C++ library, using Eclipse Oxygen and PyDev. I can debug the Python files just fine.
I run the program (pytest unit test if that matters) with a breakpoint somewhere in the test before the shared library is called (but after it is loaded) and then run a C/C++ Attach to Application debug and attach to the paused python thread. I then set a breakpoint in my C++ code and resume python, and get this from the GDB console output:
No source file named /home/myname/.../models/sourcefile.cpp
Doing an ls /home/myname/.../models clearly shows that that file exists.
I'm not sure if this matters but my library was compiled with CMake where the source and build directory are siblings. E.g. workspace is ~/dev and source is in ~/dev/sourceFolder and build files are in ~/dev/buildFolder
Update:
I was able to attach to the running Python debug thread manually in the console using gdb python <thread_number>. This works and finds my source files just fine, allowing me to debug manually in the console. It would still be much faster and less cumbersome if I were able to get it to work in Eclipse.
Things I've tried in the C++ debug config settings:
In preferences, changing C/C++ -> Debug -> Source Lookup to have
absolute file path first, profile first, and relative file path
first
In CppDebug settings debugger tab, manually added build and source directory to shared libraries
In CppDebug settings source tab, manually added source directory in source lookup path
None of these seemed to do much.
For cmake projects:
The launch configuration can default to the wrong executable, so go to launch configuration => main and check the "C/C++ Application"
Change it from this: build/default/
to this: build/cmake.debug.linux.x86_64/
(you can do this with the "Search Project" button.
This will then pick up the correct debug version and all your source will be found when you debug.
I am building an application which dynamically loads shared-libraries plugins with qtcreator on linux.
The plugin is built in a separate folder, then copied to the main application plugin folder. The application looks for plugins at startup and loads them.
Both plugin and executable are built in separate CMake projects (in Debug configuration), which are loaded in my qtcreator session.
It seems that the debugger is unable to link the library with the source code files. This has two effects
* The breakpoints I put on the plugins files are ignored
* If I put a "code breakpoint" (i.e. asm int 3) in the plugin code, the debugger shows me the dissasembly (and not the source).
How can I tell the debugger to look for the right source files ?
You may set breakpoints in libraries, based on function names and such. To view source code of break points the library must be compiled with debugging symbols (e.g. qmake CONFIG+=debug), and the source code cannot be moved after it is compiled. I believe breaking on file and line numbers also requires the source.
If you are still experiencing problems I would try adding the source directory to INCLUDEPATH, or loading both projects in QtCreator at runtime.
I have built an executable file (.exe), but when I run it, a window pops up which says
The program can't start because libgcc_s_dw2-1.dll is missing from your computer. Try reinstalling the program to fix this problem.
Can I configure Netbeans to include that file into the .exe file?
You can.
In Netbeans, right-click on the project node in the Projects window, then click Properties. Click the Build > Linker node. Under the Compilation Line category, there is a field named Additional options. Now enter the following line:
-static-libgcc -static-libstdc++
Click OK. Now it works.
Notice that your file is much larger than if it were compiled without the library. If you are not (yet) planning to distribute the executable, then maybe it's a better option to set the PATH environment variable. See The program can't start because libgcc_s_dw2-1.dll is missing for more details.
I've got a makefile based project set up that builds my code on multiple platforms. On my Mac I want to use Xcode for debugging though. I've set up an Xcode as an External Build Project I can run the application from within Xcode. The output is shown in Xcode and if the app crashes it drops in to the debugger, but when running the debugger cannot locate the source files, so I just see assembly output. How can I tell Xcode where to locate the source?
I also cannot set breakpoints, but I think that this is all the same problem.
I was able to fix the issue of not stopping at breakpoints by setting a custom working directory for the executable.
Before this change I was able to build successfully using the external scons system from Xcode 4. My code would run when called from XCode but breakpoints would be ignored.
Then in XCode,
Go to Product -> Edit Scheme...
CHeck 'use custom working directory'
and I set this to the same directory as the executable.
Breakpoints then started working.
Ensure -g is included in the compiler options in the makefile.
Set a custom working directory in the scheme, set the executable if this hasn't already been set.
Ensure that the project isn't pulling in dylibs that haven't been compiled with -g. You might need a build step to run make install if the project builds dylibs as well as the main target.
Make sure that "strip" isn't being called. There are environment vars that xcode set that allow you to keep a working makefile when used outside xcode.
Just had this problem and this worked (Xcode 4.6) (got source debugging and working breakpoints)
In "Project Navigator" (the file-folder icon just below the "Run" button), right click and select "Add Files To your-project". Browse to the top level folder where you would normally run the external build, and click Add.