Using the CodeLLDB extension, I'm successfully debugging my C projects with lldb in VSCode.
The problem is that I cannot use lldb commands in the VSCode watch window.
For example, I'm trying to print the first 10 items in an array using parray <COUNT> <EXPRESSION>.
This is what I obtain:
Is there a way to manipulate data using lldb?
For reference, with GDB you can do *myarr#10 in VSCode.
parray is an lldb command line command. It looks like the watch window expects an expression, not lldb commands. lldb's expression parser, unlike gdb's, is just the underlying language parser (e.g. it uses a copy of clang for C++). That makes it a more faithful evaluator of the expressions you hand it, but limits what debugger centric syntax we can introduce (like the gdb #10). So you could watch the elements one by one, but there isn't C syntax for "elements 0-9 of an array" so the expression parser doesn't support that either.
Presumably, VSCode has a "debugger console" for debugger commands. That's where you would enter the parray command. lldb also has stop hooks, so if you wanted to see this array's values in the console each time you stopped, you could do:
(lldb) target stop-hook add -o "parray 10 passport.data"
stop hooks can be set to trigger only for certain functions, so you could limit this printing to the function where passport is defined, as well.
Related
I always use the -x (or debug flag) when it come to bash script, or shell scripts in general.
Now i'm curious to know, is there an equivalent, either using a specific compiler options, (i use gcc, but i don't mind any other compilers) or by using a specific code in my project?
Basically i just wanted a way to emulate what bash does (using the debug flag) which show which command/function was launched first, in order, and also show the output of said function, with additional errors message etc.But for C.
I'm aware of most debug option out there, especially considering the compiler, but i really wish i could do this in my C projects too.(especially the part where it show what is executed in order, like bash does with -x)
NB: There isn't any goal in this specific question beside the question itself, as i'm just curious if this exist, and thus don't have any need for it beside the actual knowledge acquired from said answered question.
Yes, you can mimic this behaviour with a debugger.
With GDB for instance you can write "Init Files" and "Command Files" in which you can write a simple loop:
break main
run
while 1
next
end
If you put a file named .gdbinit in the directory where you start gdb, this file will be executed or gdb will lead you on the way to configure it in order that it will be executed.
The other option is to pipe this file into your gdb-call:
gdb a.out < debug_me_like-x
Where the "debug_me_like-x" file is the one mentioned above.
As a reference for the "Command Files" have a look here.
what does --interpreter-exec console "lldb command" mean ?
is it equivalent to lldb-mi command of particular lldb command?
for example to break in lldb we use "b main", but in lldb-mi we use "-break-insert main".
I am guessing --interpreter-exec console "b main" is equivalent to "-break-insert main" in lldb-mi. Please correct me if I am wrong
Equivalent but not exactly identical. b <STRING> actually does a moderately complicated job of parsing <STRING> to try to replicate (and extend) the gdb breakpoint syntax. The --break-insert MI command does a less complicated job that just supports a smaller subset of the gdb breakpoint syntax. For strings like "main" - a function name, "0x12345" - and address, or "foo.c:12" - file and line, the two are functionally equivalent, however.
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'm using lldb from the command line to debug a simple C program.
On my machine at work, I was able to use tab completion for symbol names. For example, if I type "b ma" then Tab, it'll tab-complete to "b main". The same goes for other functions.
However, I cannot get this feature to work on my laptop, where an actual tab (ASCII value 9) is inserted after the cursor. Both machines are running 10.8.4 and have the latest Xcode.
Any ideas?
I think you're running gdb on one of your two systems.
lldb can do tab completion -- it can do more sophisticated tab completion than gdb -- but you have to use the canonical form of the lldb commands for it to work. The b command you're using is an alias (a regular expression alias - a list of regular expressions that try to parse your breakpoint command and do the right thing) which doesn't give the lldb tab completion engine enough information about context to do anything.
Instead, if you were to do
(lldb) br s -n ma<TAB>
it would autocomplete. This is the short form of breakpoint set --name, of course.
The cleverness of lldb comes in to effect when you realize that lldb can tab complete lots of different arguments -- breakpoint set --filefileTab will complete "file" as a filename. breakpoint set --selector will autocomplete selector names. breakpoint set --shlib (which limits the breakpoint to only set in a specific dylib/framework/binary) will autocomplete with the list of dylibs/frameworks/binaries.
At some point in the future we want to get tab completion working with alias commands like b but no one has had time to tackle that one yet.
I need to print some structure for debugging purposes.Since the code base is huge i am having difficulty locating the exact member I need to look into.Is there some way I could print out the entire structure? or atleast know what type of structure it is so that I can go back and look into it's definition?
Use a debugger. Most debuggers give you an option to see the contents of an entire structure whenever you hit a breakpoint. On *nix the most popular debugger is gdb, and on Windows the most popular IDE (which includes a debugger) is Visual Studio. Both the sited I linked to have free-as-in-beer download links.
In gdb, you can set a breakpoint with the break command, and once you reach the breakpoint you can print the contents of the struct with the print command. More specifically, you can compile with debugging data included (the -g flag in gcc), and then use
$ gdb debugging_executable
Some basic information about GDB gets printed here
> break main.c:100
> run
> print struct_variable
It's also worth looking into the step and continue commands.
In Visual Studio, you can set a breakpoint by double-clicking just to the left of the source line (there is a gray bar on the left side of the editor), and mouse over the variable name to inspect the contents once you reach the breakpoint.