I have built the Clang program from sources with full debugging information (the default build type for Clang IIUC). I check that debug information is available in the executable by noting that there are compile units in the module:
$ lldb /opt/bin/clang++
(lldb) script lldb.target.module['/opt/bin/clang++'].GetNumCompileUnits()
1341
I have instrumented a file in the Clang source tree, lib/Sema/SemaExpr.cpp with a printf statement in the Sema::DiagnoseAssignmentResult method (which is at line 10853 in my copy). I know this method gets called on my test file test.cc, but I can't get the debugger to stop on breakpoints for this method! I have tried setting the breakpoints two ways,
$ lldb /opt/bin/clang++
(lldb) breakpoint set -m DiagnoseAssignmentResult
Breakpoint 2: where = clang++`clang::Sema::DiagnoseAssignmentResult(clang::Sema::AssignConvertType, clang::SourceLocation, clang::QualType, clang::QualType, clang::Expr*, clang::Sema::AssignmentAction, bool*) + 87 at SemaExpr.cpp:10858, address = 0x0000000100ab9947
(lldb) process launch -- ./test.cc
<< message from my printf statement >>
... then clang++ runs to completion and exits, no breakpoint hit ...
(lldb)
I note that lldb did find the correct place in the source code, but didn't stop when it passed through the method. I also tried setting the breakpoint by specifiying the file and line number,
(lldb) breakpoint set -f SemaExpr.cpp -l 10853
Breakpoint 3: where = clang++`clang::Sema::DiagnoseAssignmentResult(clang::Sema::AssignConvertType, clang::SourceLocation, clang::QualType, clang::QualType, clang::Expr*, clang::Sema::AssignmentAction, bool*) + 87 at SemaExpr.cpp:10858, address = 0x0000000100ab9947
Again it "worked", but does not stop. Am I doing something fundamentally wrong here? How can I get the breakpoint to trigger?
You are debugging the clang driver, which is not what actually does the parsing. Instead, clang spawns off another process to do the compilation, then ld if linking is needed, etc. lldb wasn't stopping at your breakpoints because that code was actually getting run by a child process. The confusing bit here is that clang actually uses the same binary for the driver and the parser, so the breakpoints took, just not in the version of clang that was going to invoke that code.
The way to debug the compilation part of clang is first to run it like this:
$ clang++ -### <all your other arguments>
Note the weird -### argument. That tells clang not to do the compilation but to emit the command line that it will run to do the compilation. It will look something like:
/usr/bin/clang" "-cc1" ...
So that is the command line that you want to use in lldb to debug clang as a compiler rather than clang as a compiler driver...
Related
I am having trouble getting the debugger to work properly when setting up clang on my Windows 10 machine. Compilation seems to work OK, at least for the simple "hello, world" program I tried. However, when I try to run the lldb or gdb debuggers on this test program (or any other program I tried), it does not recognize function names.
Here's my C program code:
#include <stdio.h>
int main(void) {
puts("Hello, world!");
return 0;
}
Nothing too spectacular here, I know. I'm compiling with the following command:
> clang -g -O0 hello.c -o hello.exe
I then try to run the debugger:
> lldb hello
(lldb) target create "hello"
Current executable set to 'hello' (x86_64).
(lldb) b main
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
(lldb) r
Process 12156 launched: 'C:\Users\********\Projects\clang-test\hello.exe' (x86_64)
Process 12156 exited with status = 0 (0x00000000)
(lldb)
Apparently the symbol "main" was not recognized, and the program did not halt at the start of the "main" function but ran to completion (in a different console window, hence no program output here).
How do I get debugging symbols to work? In a different stackoverflow answer I found that adding compiler options "-g -O0" should do the trick, but as you can see that does not solve the problem for me. I also found a different stackoverflow answer about how to set up debugging if the code is not in the same directory as the executable, but that is not relevant to my case: the current working directory is the same as the directory with the code and executable in them.
Some version information:
> clang --version
clang version 9.0.0 (tags/RELEASE_900/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
> lldb --version
lldb version 9.0.0
The "-g -O0" options you provided should indeed let the debugger know all the symbols it needs from the executable.
Therefore, I suspect the problem is elsewhere, perhaps with your terminal, or your version/implementation of LLDB.
Are you using the windows cmd.exe commandline ? or something else, like Powershell ?
I've never managed to get debuggers working properly in those environments, but it was much easier with Cygwin, which is a bash shell for windows (it creates a "simulated" linux environment within its install folder, so you have all the /usr,/bin,/etc folders a bash shell needs)
This way you can actually use gdb the way you would on a UNIX system.
If the above method sounds like more of a hassle than a time-gain, then yeah I would recommend another debugger altogether, like the Visual Studio debugger.
In fact, maybe a memory-analysis tool like Dr.Memory can give you what you need
I have a problem with GDB. When I use "s" to step into a function called from the main function, GDB jumps to another function without showing me the function that I need.
To be clear, I use step here:
In file main.c:
short c = get(a, b);
Now get has a 36 lines code and at line 27 it calls an other function "swap" here:
In file get.s:
call _swap;
When I use step (s) with GDB on "get", it jumps all of the get function and it shows me the _swap function.
These are three different files: main.c, get.s, and *swap.c compiled in this way:
gcc -g -m32 main.c swap.c get.s -o IA-main
-m32 because get.s is IA-32 assembly. Why does it jump the "get" function and show me only "_swap"?
I work on Mac OS X v10.12.6 (Sierra), so GDB is a little annoying.
From Continuing and Stepping (emphasis mine)
step
Continue running your program until control reaches a different source line, then stop it and return control to GDB. This command is abbreviated s.
Warning: If you use the step command while control is within a function that was compiled without debugging information, execution proceeds until control reaches a function that does have debugging information. Likewise, it will not step into a function which is compiled without debugging information. To step through functions without debugging information, use the stepi command, described below.
You can use the stepi command instead:
stepi
stepi arg
si
Execute one machine instruction, then stop and return to the debugger.
It is often useful to do ‘display/i $pc’ when stepping by machine instructions. This makes GDB automatically display the next instruction to be executed, each time your program stops. See Automatic Display.
An argument is a repeat count, as in step.
I've never used a debugger and the time has come to give them a try. MinGW appears to come with GDB which I've been trying to use. Supposdly running gdb from the command line and typing run myprog.exe starts the debugger but when I do this I get
Starting program: C:\MinGW\bin\myprog.exe MyProg.exe
[New Thread 1828.0xd8c]
Error opening file.
[Inferior 1 (process 1828) exited with code 02]
How to proceed or what's an easier way?
In particular I'm trying to flush out undefined behavior.
Since your program terminates, you'll need to set a breakpoint to see anything. Try break main before the run line. Then you can do commands line next (next line), step (step into/outof function calls), print expression (where expression can be a variable name or a function-call or a calculation), display expression (same as print, but prints just before each prompt). At any given point you can type backtrace to get a call stack. You can even type up and down to move up the callstack, so you can print higher local variables.
Well, the easiest way would be to use an IDE, actually. You might want to give code::blocks a try - very easy to use, configures everything for you on installation (just make sure to pick a compiler - don't worry, it'll prompt you) and there, you're all set and ready to go. As it's multi-platform, it doesn't really lock you into windows either, and gives you very powerful (and, I guess more importantly, convenient) possibilities of graphical debugging.
pass the binary with gdb
gdb <binary>
then set breakpoint to main
gdb) break main
Then run your program in gdb
gdb) run
then break point hits use 'n' or 'next' to step to different lines
gdb) n
Use 's' for stepping into function and 'p' printing var value
Example :
gdb) s <fun_name>
gdb) p x
I would suggest , as a beginner start off with Visual Studio. It has a very good and easy to use debugger. Just create a break point in the line from which you want to start debugging (click on the left bar beside the line or right click and create a break point). Once your break points are set you can just simply run the program in debug mode and the execution of the program will halt in the point where the break was created.
At this point you should be able to view all valuable information about the execution of the program. You can use F10 to continue the execution step or F11 to step inside the execution tree.
The debugger as many other advanced features like break on condition , hit count etc but you can start off with it's basic functionality.
If I compiled a program like this:
gcc -o my-prog -g myprog.c
I could then debug the executable my-prog it like this:
gdb my-prog
The -g option tells gcc to generate full debugging info. Other compilers will have their own versions of this option (e.g. the MSVC cl command has the /Zi option).
Since you're having issues running the gdb on your program, it might be worth checking if it was compiled with debugging info in the first place. The debugging info is usually generated in the same location as where you compiled your program.
I have been asked in an interview how can you debug segmentation fault in C program using GDB.
I told them we can compile our program with -g option so as it add debugging information to binary file and can read core dump file but then interviewer told me if he we have 3 to 4 files compiled together but one of them causing segmentation fault then how do we debug in GDB?
$ gcc -ggdb s1.c s2.c s3.c -o myprog
$ gdb myprog
(gdb) run --arg1 --arg2
GDB will run the program as normal, when the segmentation fault occurs GDB will drop back to its prompt and it will be almost the same as running GDB with a core file. The major difference is there are some things you cannot do/print with a core file that you can when the program has crashed inside of GDB. (You can use print to call some functions inside the program, for example.)
You can also attach to an already running program using gdb --pid <the programs pid>.
Either with a core file or with one of the methods above, when you have the GDB prompt after the crash, type backtrace (or bt for short) and GDB will show you the stack at the time of the crash, including the file names and line numbers of each call and the currently executing line.
If you are working under Linux the easier way to find segmentation fault is by using the tool named VALGRIND: http://valgrind.org/ .
You just need to compile your code with -g flag and then run ./valgrind .
Then you will know exactly in which function and in which line of code there is an error-uninitialized memory/memory read out of allocated space or sth.
You just run the program under gdb, and the debugger with catch the SIGSEGV and show you the line and instruction that faulted. Then you just examine the variable and/or register values to see what's wrong. Usually it's a rogue pointer value, and trying to access it with GDB will give and error, so it's easy.
And yes, recompiling everything with -g would be helpful. The interviewer probably wanted you to describe how you'd figure out which file had the fault (gdb just tells you when it catches the signal) and just recompile that one with debug info. If there's 20,000 source files that might be useful, but with 3 or 4 files, what's the point? Even with larger projects, you usually end up chasing the bad pointer through 10 functions and 5 files anyway, so again, what's the point? Debug info doesn't cost anything at run time, although it costs disk space in an installation.
compile the code in normal way by giving gcc filename
you will get a .out file, start running that and get the process id by giving ps -aef | grep filename.out
in a another window type gdb and enter,inside gdb prompt give attach processid (processid you will get from above command),give c to continue.once the execution finishes give "bt" inside gdb.you will get the place where the segmentation is occurring.
Sounds like they are looking to set it up so that you can step through the code as it is running, you can do this with the command line version or I think you can get a GUI for GDB.
one can use the following steps to debug segmentation fault using gdb
$ gdb <exec name >
$ r //run the pgm
$ where
$ f <1> <0> //to view the function n variables
$ list
$ p <variable>
While debugging a C program in gdb I have a breakpoint in a for loop. I cannot print the value of "i" ( I get : No symbol "i" in current context.). I can print the value of all the other variables. Is it normal?
Here is the loop:
for (i=0; i < datasize; i++){
if ( feature_mask[i] > 0 ){
k = feature_mask[i] - 1;
if (neighbors[k][nmax-1] != 0){
neighbors[k][nmax-1] = bvalue;
feature_mask[i] = -feature_mask[i];
}
}
}
It has probably been optimised out of your compiled code as you only use feature_mask[i] within the loop.
Did you specify an optimization level when you called your compiler? If you were using gcc, then just omit any -O options and try again.
I encountered this issue recently. I compiled GCC 5.1 and then used it to compile a C++11 codebase. And, although I could step through the program's code in gdb, I couldn't print the value of any variable, I kept getting “No symbol "xyz" in current context” errors, for every variable.
I was using gdb 7.4, but the latest version available at the time was 7.9. I downloaded the latest version of gdb and compiled it (using GCC 5.1) and when using gdb 7.9 I was able to successfully inspect variable values again.
I guess the debug information of GCC 5.1 is incompatible with gdb 7.4.
Make sure the program is compiled without optimization, and with debugging information enabled. It's quite likely that the loop counter ends up in a register.
Check your optimization options. It's possible the GCC could replace the variable with a pointer into feature_mask.
You can try declaring i as volatile. That will prevent some compiler optimizations (and hopefully make i visible inside the debugger).
In case anyone else is using Google's Bazel build system for your project, I'd like to add that if you cannot print any variables from gdb, it may be because you need to properly add the -ggdb and -O0 (update: use -Og instead of -O0 use -O0 over -Og) C build flags using the --copt= option, INSTEAD OF using the --per_file_copt= option. In my case, although they both built and ran just fine, only the --copt= technique allowed me to fully use gdb and print variables, whereas the --per_file_copt= one also allowed me to use gdb but would NOT allow me to print variables.
Note: in the below examples, just replace test with build if you do NOT need to run the unit tests as well.
UDPATE: it turns out, you should prefer -Og over -O0 when doing debugging, so I'm updating these examples accordingly. See here: What's the difference between a compiler's `-O0` option and `-Og` option?.
So, do this:
time bazel test --copt=-ggdb --copt=-O0 \
//my/build/folder1/... //my/build/folder2/...
INSTEAD OF this:
time bazel test --per_file_copt=//my/build/folder1/...,//my/build/folder2/...#-ggdb,-O0 \
//my/build/folder1/... //my/build/folder2/...
...in order to be able to print variables from within gdb.
Again, both of the above techniques build and run just fine, and both allow me to run and use gdb, but only the first one actually allows me to use gdb to its full extent.
Lastly, if the first command above still doesn't work, try adding the --strip=never Bazel flag described here to prevent Bazel from ever stripping debugging information. Now the command will look like this:
time bazel test --copt=-ggdb --copt=-O0 --strip=never \
//my/build/folder1/... //my/build/folder2/...
Reference documentation:
--copt=:
https://docs.bazel.build/versions/master/command-line-reference.html#flag--copt
[better, with examples] https://docs.bazel.build/versions/master/user-manual.html#flag--copt
--per_file_copt:
https://docs.bazel.build/versions/master/command-line-reference.html#flag--per_file_copt
[better, with examples] https://docs.bazel.build/versions/master/user-manual.html#flag--per_file_copt
--strip=never:
https://docs.bazel.build/versions/master/user-manual.html#flag--strip
[my own Q&A] Prefer -Og over -O0 -O0 over -Og for debugging: What's the difference between a compiler's `-O0` option and `-Og` option?