I'm having trouble using lldb to debug on MacOsX with clang++. I'm using a makefile to compile a projet in C++, and I don't know if the debug option has to be enabled in the compilation command.
Here is an extract of my makefile
FLAGS =-g -Wall -O0
[...]
clang++ $(FLAGS) $^ -o $#
When I try running lldb with this configuration of my makefile, it return an error :
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
I suppose I have to enable the debug tools on my makefile, but I haven't found how to do this on internet. I tried with the -g and the -ggdb options, without success.
However, when I try to set a breakpoint differently, it works (but setting a breakpoint on a specific fonction doesn't interest me...) :
breakpoint set -n fonction
Breakpoint 1: [...]
I didn't manage to find answers on internet, so I would be interested in having some help ! Thank you !
It looks like somewhere along the way the debug information is getting lost. One possibility is that your CFLAGS are getting reset before you get to building the .o files you care about, so the .o files don't have debug info. One easy way to check that is run
$ otool -l my_file.o | grep debug_info
sectname __debug_info
If you don't see that "sectname" output, then your .o file has no debug information.
Run your makefile and look at the build line for my_file.c and make sure there really is a -g option being passed. -ggdb doesn't actually do anything special for clang so -g is all you need...
If the .o file has debug information, then it must be getting lost when you build the final binary.
Mac OS X is a little funny in how it handles debug information. It doesn't write the debug information into the final image, but rather writes a "debug-map" into the executable, and leaves the debug info in the .o file. That debug-map gets stripped when you strip a binary, so if you strip your executable that will remove the link to the debug information. And of course, if you delete the .o files after building, that will also remove the debug information.
I finally installed gdb, and I managed to debug normally. But after reading your post, you make me realize I have maybe delete the .o when compiling. I didn't thought about it, as lldb was able to set break point in some cases (at a specific fonction) but not in other cases (at a specific line).
As I am using a makefile, I forgot to delete the auto delete of all the .o after compiling, and I think that may cause the issue. Now, if I let the .o, that works perfectly. But this is surprising me a lot, as my makefile was the same as my colleague and he was able to debug with gdb without any kind of problem.
Thanks a lot for all your informations.
Related
I have to submit a makefile for a project and I can't get it to work. I am trying to use the appropriate c++ 11 standard, execute project2,out, and run the cpp files in my src, but I keep getting the error "Nothing to be done for 'Makefile'."
#specify std=c++11 in your makefile
CXXFLAGS += -std=c++11
#Your executable should be named project2.out
main: g++ -o project2.out src/*.cpp
clean: del *.o
When asking questions please always cut and paste the exact command you typed and the exact output you got, properly formatted for SO (if you get a lot of output trim it down to the relevant parts which includes the command make invoked and at least the first few (not last!!) errors you get).
In this case, if you'd shown us what command you were running I'll bet it's this:
make Makefile
that's wrong. The arguments to make are not the makefile to use: they're the target you want to update. Here you've asked make to update your Makefile, but it already exists so make says "nothing to do".
Just run:
make
to build the default target, or make clean to build the clean target.
Once you get past this, you can begin to work on why your makefile may or may not work.
I've recently installed a vim editor in my Windows operating system.
I only know the conventional procedure i.e, creating the source file in the editor and running it from the command line. But,
I don't quite understand how to compile a CPP program directly from the vim editor.
when I run the command
:!g++ hello.cpp -o hello
from the vim command line, I get the following message
C:\WINDOWS\system32\cmd.exe /c (g++ hello.cpp -o hello)
Hit any key to close this window...
I assume your version of Vim is windows version and not cygwin version.
First you need to install a compiler, and make sure it's in your PATH.
Also, read the documentation about quickfix window as this is the integrated vim way of compiling. :!make or :!g++ ... are not the way to go.
MSVC
I don't suppose this is the compiler you have as I expect you'd have used Visual Studio in that case. Anyway, IIRC, there is a msdev compiler plugin you could load with :compiler msdev, then you should able to run :make.
Don't hesitate to complete my answer if you see errors.
g++ through cygwin
There is a big advantage: gnumake is properly configured: in the console you could run make foo, and if you have foo.cpp or foo.c and no Makefile in the current directory, this would compile the monofile project. In all cases, a Makefile is fine; and it's required with multiple source files.
The big problem: pathnames are not expressed in the same way. They need to be translated. I provide a way to do that in my Build-Tools-Wrapper plugin. Just execute :BTW add cygwin.
Then from vim, again type :make %<. That will translate into :make foo (assuming you're editing foo.cpp), which translates into make fooshell wise, which translates into $CXX $CPPFLAGS $CXXFLAGS $LDFLAGS foo.cpp -o foo $LDLIBS (or something like that).
Note: this means the options can be tweaked with: :let $CXXFLAGS = '-std=c++17 -Wall -Wextra'
BTW, if you have my build-tools-wrapper plugin, you can execute directly :Make instead of :make %<, or just <F5>directly, IIRC.
g++ through mingw
The good news: no need to translate pathnames
The bad news, gnumake isn't correctly configured. This means that in the console make foo won't work. And consequently, this won't work from Vim.
This time, you'll either need a Makefile, or you'll need to tweak 'makeprg' setting. Like for instance :let &makeprg = 'g++ -Wall -Wextra -std=c++17 -o %< %' and then type simply :make.
I've got a source base in C using autoconf/automake, which now should be compiled using a C++ Compiler.
So I've renamed all files from .c to .cpp and changed all makefiles accordingly. However I get the following error (e.g.):
make[3]: *** No rule to make target 'tmsConfigFiles.c', needed by 'tmsConfigFiles.o'. Stop.
The Makefile basically consists of
bin_PROGRAMS = configparser
configparser_SOURCES = tmsConfigFiles.cpp tmsMoreFiles.cpp tmsEvenMoreFiles.cpp
AM_CXXFLAGS = -I .. -DSOME_DEFINE -Wall -Wextra -etc
This works for the overwhelming parts of the source code (some of which were cpp from start) but for some files the error message above appears. Did try to clean and autoreconf -is etc. to no avail.
The same revision works on Centos 6, fails sometimes on Centos 7, failes always on my Arch box.
Anyone had a similar bug in autotools or knows a workaround?
The obvious thing that I can think of is that you have not re-executed automake (or more properly autoreconf) after changing Makefile.am, and for whatever reason (there are more than a few ways for that to happen) you don't have maintaner-mode enabled.
This is, though, assuming you are actually editing Makefile.am to begin with. If you actually edited Makefile, then it's the opposite problem, automake is doing the right thing and ignoring altogether your changes by re-generating the file that should not be edited.
git clean -fx did not remove .deps directories.
Removing them manually solved the issue.
I followed the instruction from this video to run the code line by line:
http://www.youtube.com/watch?v=6CGH9Z19dS8
However, after I pressed F8, it just ran without going to the breakpoint(I couldn't see the yellow triangle). In addition, I also tried "attach to process", and it was the same.
Did I miss anything?(btw, there are multiple files in my project, but I guess that won't be the problem, right? cuz I could do this easily in VS studio. Perhaps, I am not that familiar with codeblocks)
Thanks for help!
If you are interested, this is the debugger log:
Building to ensure sources are up-to-date
Selecting target:
Release
Adding source dir: C:\Users\liuca_000\Documents\Lattice_Boltzmann_code\lattice_boltzmann\
Adding source dir: C:\Users\liuca_000\Documents\Lattice_Boltzmann_code\lattice_boltzmann\
Adding file: C:\Users\liuca_000\Documents\Lattice_Boltzmann_code\lattice_boltzmann\bin\Release\lattice_boltzmann.exe
Changing directory to: C:/Users/liuca_000/Documents/Lattice_Boltzmann_code/lattice_boltzmann/.
Set variable: PATH=.;C:\Program Files (x86)\CodeBlocks\MinGW\bin;C:\Program Files (x86)\CodeBlocks\MinGW;C:\Python27\Lib\site-packages\PyQt4;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Python27;C:\Python27\DLLs;C:\Python27\Scripts;C:\Python27\Lib\site-packages\vtk;C:\Python27\gnuplot\binary;C:\Python27\Lib\site-packages\osgeo;C:\Program Files (x86)\pythonxy\SciTE-3.3.2-3;C:\Program Files (x86)\pythonxy\console;C:\MinGW32-xy\bin;C:\Program Files (x86)\pythonxy\swig;C:\Program Files (x86)\pythonxy\gettext\bin;C:\Program Files\MATLAB\R2012b\runtime\win64;C:\Program Files\MATLAB\R2012b\bin;C:\Program Files\TortoiseSVN\bin;C:\Program Files\MiKTeX 2.9\miktex\bin\x64;C:\Program Files (x86)\Windows Live\Shared;C:\Users\liuca_000\AppData\Roaming\MiKTeX\2.9\miktex\bin\x64;.;\
Starting debugger: C:\Program Files (x86)\CodeBlocks\MINGW\bin\gdb.exe -nx -fullname -quiet -args C:/Users/liuca_000/Documents/Lattice_Boltzmann_code/lattice_boltzmann/bin/Release/lattice_boltzmann.exe
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Reading symbols from C:\Users\liuca_000\Documents\Lattice_Boltzmann_code\lattice_boltzmann\bin\Release\lattice_boltzmann.exe...(no debugging symbols found)...done.
Debugger name and version: GNU gdb (GDB) 7.5
Child process PID: 16672
[Inferior 1 (process 16672) exited normally]
Debugger finished with status 0
Even if you have had marked -g compiler option the problem may be spaces in path to the project file. Moving to place with no spaces in path solved the problem in my case.
See that: http://wiki.codeblocks.org/index.php?title=Debugging_with_Code::Blocks#Path_with_spaces
I think this part of your log says why:
(no debugging symbols found)
build a debug version of your code - no optimisation, debug symbols included or built and try again.
Spent quite a while working through this today trying:
"Make sure using "debug" instead of "release"
"No spaces in directory names"
"-g ticked, -s unticked"
"download a nightly"
None worked until, I figured I had been making a very novice mistake unfamiliar with the IDE and to debug so it stops at the break points you have to run with the red arrow not the green one. So anyone as silly as me hopefully this helps! xD
You seem to have found a solution that is the wrong solution and likely
to have adverse consequences. (Apologies if I am mistaken)
Your were unable to set breakpoints because your build contained no debugging
information (as you now know); and the build contained no debugging information
because you were trying to debug a Release build and not a Debug build.
You can see this in the build log:
Adding file: C:\Users\liuca_000\Documents\Lattice_Boltzmann_code\lattice_boltzmann\bin\Release\lattice_boltzmann.exe
and also:
Reading symbols from C:\Users\liuca_000\Documents\Lattice_Boltzmann_code\lattice_boltzmann\bin\Release\lattice_boltzmann.exe...(no debugging symbols found)...done.
The executable generated by a Release build will be <project_dir>\bin\Release (as it is), and the executable
from a Debug build will be in <project_dir>\bin\Debug
It appears that you have "solved" the problem by going to Build Options -> Compiler flags and ticking
the checkbox Produce debugging symbols.
But if you go back there and look at the tree control at the left of the window I expect you
will see:
lattice_boltzmann
Debug
Release
with Release selected. That means you have now configured your Release build
to contain debugging information. You don't want that because:-
Although you will now get debugging symbols in the executable and the debugger will be able to use them, the Release build is still configured with high optimisation by default (as it should be) and you are very likely to find that the behaviour of the debugger is at times strangely puzzling, because the optimized object code doesn't always properly match up with the source code.
Your Release executable will be vastly inflated in size by the debugging information.
What you should have done is simply to ensure that the build you tried to debug was
a Debug build. To do that:
Navigate from the top menu bar Build -> Select Target
Uncheck Release. Check Debug
Then Rebuild the project (i.e. clean and build) and you will be able to debug it
properly. Code::Blocks default options for a Debug build are perfectly fine.
Don't forget to go back and remove the -g option from the Release configuration.
I'm working on a really big project which I would like to debug with gdb. Unfortunately, compiling with -g flag takes two days and a half and output libraries that are larger than 60Go (project takes ~1Go without -g).
is there a simpler way to obtain a symbols table (i.e. be able to backtrace) and if yes, how ?
I've seen that gdb offers three levels of debugging (-g level as described here), would it help ? Would string ?
Thanks in advance.
For a backtrace with just function names, you don't need -g at all.
For a backtrace with file and line info, using recent GCC versions, try -gmlt option (minimal line table). Note that no local variable info will be available in GDB.
If you want local variables, you'll probably want to use -gdwarf-4.
The documentation you pointed at is for gcc-2.95. That is an ancient version. If you are still using it, your first task should be to switch to (current) gcc-4.6.2
If you have an idea about source files you want to debug compile them with -g option. Make sure you link with -g option too. Now you have a partial debug image.