I compiled Xcode project in debug mode. however, while running it from VM with lldb (or any other remote machine), I cannot see any debug symbols.
to resolve this I've created a soft link to the project source code in local compilation machine, so that each file will have the same path.
however, unlike local VM, in remote machine i might not have source code access.
so my question is what files should i copy from project debug outputs in compilation machine, to remote machine so that the lldb debugger will recognize target symbols, and how should i "tell" lldb to look at those new data, rather than the original symbols location (in compilation machine)
In the normal build/debug cycle lldb reads debug information from the .o files made in the course of the build. There's a "debug map" in the binary produce that points to the locations of these .o files. Since the debug map records absolute paths, if you want to use the .o files on another machine the .o files must appear in the same place on the file system as they are on the builder.
The other way to do this is to use Xcode's "DWARF + dSYM" variant of debug info generation, which builds a ".dSYM" folder that contains fully linked debug information. Then just move the dSYM & the binary to the same directory and lldb will find it. If for some reason that doesn't work, there is also an lldb command: add-dsym that you can use to manually tell lldb where the dSYM is.
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 have set my project to output my .exe file into a specific directory, and if I run this compiled executable outside of Visual Studio, it can find and use the files around it using cstdio. However, if I run it within Visual Studio, those files are suddenly gone, as if it's in the wrong directory.
What is causing this, and how might I fix it?
Visual Studio will run the program that's "over there" in its own project folder, so the program's working directory, where it creates and looks for files etc..., will be the project directory and not where the executable is stored.
You can do this yourself. Open a command prompt and type the full path to the executable. It will run, write, and look for files in the prompt's current folder.
Do not use argv[0]. this will give you the command line, and might not include the actual location of the executable.
If you want to keep your files with the executable no matter where the program is run from, GetModuleFileName will tell you where the executable is. You can then strip off the executable to get the path and concatenate that with the names of other files you want to stay in the same folder as, or relative to, the executable. With this approach you can run the program from anywhere, including Visual Studio.
If you want to know where the executable is being run from and make your own way, use _getcwd.
If all you care about is Visual Studio, navigate to Project->Properties->Configuration Properties->Debugging and set the Working Directory to the target directory
I will assume that what you really want to do is to copy the executable elsewhere after the build. That way you don't have to have anything special in the executable that is only for debugging (development). You can have Visual Studio do the copy for you automatically using a Custom Build Step. The build should create the executable in the same project directory that it normally does, then the copy will be done after that (like a mini deployment).
In the project's properties:
Select "Build Events" | "Post-Build Step"
Enter a post build event command to do the copy, for example:
copy "$(TargetDir)$(TargetFileName)" "G:\Temporary"
Where "G:\Temporary" is wherever you want the file to be copied to.
Be mindful of the configuration. You can choose to create the Custom Build Step for both debug and release configurations, but then the executable will be copied to the same place for both configurations. You probably will want a different copy command for each configuration.
While in the property page for entering the Custom Build Step, you can click the down-arrow and select "Edit..." (inside the less than and greater than symbols) to get help creating the command. While doing that, click on "Macros>>" to see the big list of available macros.
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 made C++ application to use with WinDbg, and intentionally add access violation run-time error.
Application was compiled as release build, and then I copied exe from release folder to desktop. Still when I use WinDbg, and application crashes, it open my source code file showing error line highlighted.
I am not able to understand, how WinDbg understand my source code file path.
Also, when I get crash dump from client, it may be possible, I do not have source code available with me. So I want to simulate real world scenario.
Regards
The way I understand it, Visual Studio compiler generates a .pdb file for any executable it creates (when /DEBUG flag is set). This PDB (Program Database) file contains information (including paths to source files) required for the debugger to match address in a binary module to source code. And it seems that a path to .pdb is hard-coded into the binary. So when you move a binary itself, debugger can still find pdb, from which it finds the sources.
All paths are probably absolute and will only work on the PC which compiled the binary.
.pdb has source file full path name information. open a .pdb file you will see lines like this:f:\dd\vctools\crt\crtw32\stdcpp\locale0.cpp