According to the official guideline of lldb, the ability to view source code during debug session (using the command source list) is done by setting new pathname for source files.
i.e. if i compiled my project in /tmp on one computer and deployed it on another computer where the source code reside in /Users/Src/ , i should type settings set target.source-map /tmp /Users/Src from running lldb in the deployment machine.
However, what happens if i got the executable from someone else, and don't know the build directory. and maybe the source-code is organized differently from where is was built (but the file contents is the same).
my questions are :
Does lldb know how to search for matching source file recursively in the supplied path ?
How can I get the original pathname form the mach-o executable ?
here's the formal description of the command :
Remap source file pathnames for the debug session. If your source files are no longer located in the same location as when the program was built --- maybe the program was built on a different computer --- you need to tell the debugger how to find the sources at their local file path instead of the build system's file path.
If you know a function name in the code in question, do:
(lldb) image lookup -vn <FunctionName> <BinaryImageNameContainingFunction>
and look for the CompileUnit entry. The path given there is the path lldb got from the debug information.
Related
I'm trying to run a single program that opens a image file in Clion C++:
See image:
As you can see here, i have a file named "Reso" and a image named "test.png", but this code always will promt "Error reading image"
NOTE: I have proven that this does work in Visual Studio perfectly, but for some reason the file is not recognized in Clion
When you run a binary in CLion, your application will have by default the current working directory set to where your binary is located, which is probably somewhere in your cmake-build-debug directory.
In your case you expect a certain directory, because your resource file is somehwere else. You can either change your code to allow passing the path by argument, or you can set the working directory in CLion for your binary.
In the top you have this bar, where you can choose your build target. There is an option Edit configurations and when you open this and select your target, you can see a field Working directory. Set this field appropriate for your project.
I have an executable that was built with g++ -O0 -g (GCC 4.3.4) and immediately the source code was archived. At a later time it was altered. I now want to debug the original version. The executable saved the location of the original source code, which right now is populated by a different version with the same file names. I want to point GDB (GNU gdb (GDB) SUSE (7.5.1-0.7.29)) to the old source code. I have extracted it to a new location. I have tried setting the directory and substitute-path. Each time the loaded source code is the modified version. The commands I'm using are:
set directories /.../PILAGER2/unzip/source/
set substitute-path /.../PILAGER2/source/ /.../PILAGER2/unzip/source/
I have replaced the bulk of the path with /.../.
However if I type info source when the break point is reached the wrong file is shown. If I delete the files from the original location the correct ones are used. How do I properly tell GDB to use the source files from the unzipped location?
In my case the disk system was on a separate server. Using the path supplied by the administrators was actually a link to a location on a parallel fileshare. Using the actual path on the Panasas system worked. In my case that means the path started with /panfs/ followed by the server instead of /project/...
I'm trying to use Mac Instruments Time Profiler to optimize my code for building a MandelBox. I found how to make my executable my target process, but when the program runs, it gives me an error in the Console window saying it cannot find the .txt file associated with the program.
Do I need to tell the profiler where to look to find the file? The text file is already in the same directory as the executable. Any thoughts? Thanks.
This problem is not unique to Instruments. The same thing would presumably happen if your current working directory was something other than the location of your program. For example, if you were to do cd / ; /path/to/yourprogram.
You either need to make your program find its own location and then find its text file as a sibling in the containing directory or take the path of the text file as an argument. Or, you will always have to set the working directory to your program's location before invoking it.
That last approach is an immediate workaround for the problem with Instruments. On the panel where you choose the target executable, you can also configure various parameters, such as arguments, environment variables, and the working directory. Set the working directory to the directory that contains the text file and it should work.
When I build, it succeeds with no errors. However, when I run from the IDE, I get an error (my image fails to load because it cannot find the directory).
However, if I go into the folder and run the program(.exe) it finds the image directory perfectly.
mTextures.Load(Textures::Background, "../GFX/Background.png");
^the line of code giving the directory.
I assume this is a problem with a setting I didn't enter correctly in my compiler?
I am using Code::Blocks on Windows.
Your debugger's current directory (i.e. the current directory used when you execute the application from within codeblock) is probably incorrect. Check your project settings, and fix the current directory to your target directory (the one which contains the executable itself).
Specific instructions are here.
It's because you're using a relative path in your file name:
"../GFX/Background.png"
the .. is saying "go up one directory form the current directory". If you want to be able to run your program anywhere, use an absolute path, something like:
"/home/me/GFX/Background.png"
Add the full path where the image exist with double slash.
mTextures.Load(Textures::Background, "C:\\Program Files\\..\\..\\GFX\\Background.png");
My C++ project folder structure is as shown below.
I am trying to debug the program using gdb in my linux machine. My main function is in g2o.cpp which is inside g2o_cli folder. I am able to put breakpoints in the files in this folder by
break g2o.cpp:<line_number>
But I am not able to put breakpoints in the files in other folders, for example, a file optimizer.cpp in the 'core' folder. I tried giving the absolute path from my home directory
break ~/HOME/g2o/core/optimizer.cpp:<line_number>
but it is giving an error
No source file named ~/HOME/g2o/core/optimizer.cpp
I also tried ../../core/optimizer.cpp instead of the absolute path. Still it did not work.
I saw a similar question here. But none of the possible reasons mentioned in the answer is applicable in my case. The file optimizer.cpp is not a shared library and the entire project was compiled using cmake.
How does gdb take folder paths? How can I give the relative folder path?
A dirty hack you can use on x86 is to use int3. Just use the statement asm volatile ("int 3"); in the code where you want the breakpoint.