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.
Related
I want to quickly compile and execute C code, see the output, and then resume editing with just one shortcut key.
I installed the c/c++ compile run extension which compiles and executes the file and shows the output in the terminal. However, that leaves the terminal focused and I have to manually jump back to the editor.
I tried using a macro extension to string together two commands: one to compile and execute and one to jump back to the editor, but that didn't work. It just leaves me in the terminal.
UPDATE
OK, I modified the command macro to this in settings.json:
"macros": {
"execCMacro": [
"extension.CompileRun",
"workbench.action.focusFirstEditorGroup",
"workbench.action.focusFirstEditorGroup"
]
},
Note the duplicate command for putting the focus back to the first group. Probably has something to with it taking time for the terminal to get focus.
This probably isn't the best solution. Is there a command for inserting some short delay I might use? The macro uses the "macro-commandeer" extension.
I am using Delphi 2007. I know how to get the IDE compiler to suppress/ignore particular warnings.
But how do I get the command line compiler to do this ?
You use the -W-[WARNING] option. The following example turns off W1036 ("Variable %s might not have been initialized"):
dcc32 test.dpr -W-USE_BEFORE_DEF
The only way I've found to find out the warning name to use is to create a simple console project in the IDE, add code that will produce the warning you want to identify, and then set the Project->Options-Compiler-Hints and Warnings to suppress that warning. Then build your project. Show the Messages window, go to the Output tab, Ctrl+A to Select all, Ctrl+C to copy.
Create a new console app.
program Test1;
{$APPTYPE CONSOLE}
uses
SysUtils;
begin
WriteLn('Test1');
ReadLn;
end.
Use Project->Options->Compiler`->Hints and Warnings, and turn off the warning(s) you want to suppress.
Build your test project.
In the Output tab of the Messages window, select all (Ctrl+A or using the context menu) and copy to the clipboard (Ctrl+C or via the context menu).
In a new Notepad window (or a new editor tab), paste in the contents of the clipboard. You'll find a long block of dcc32.exe command line similar (but probably much longer) than this (I've emphasized the relevant parts to notice):
Build started 02/05/2016 2:48:48 PM.
Project "E:\Code\Project1.dproj" (Make target(s)):
Target CoreCompile:
c:\rad studio\5.0\bin\dcc32.exe -DDEBUG;DEBUG -I"c:\rad studio\5.0\lib";"c:\rad studio\5.0\Imports";"C:\Users\Public\Documents\RAD Studio\5.0\Dcp";E:\Code\FastMM4;E:\madCollection\madBasic\BDS4;E:\madCollection\madDisAsm\BDS4;E:\madCollection\madExcept\BDS4;"E:\Code\Virtual Treeview\Source";E:\code\Indy10_5294\Lib\Core;E:\code\Indy10_5294\Lib\System;E:\code\Indy10_5294\Lib\Protocols;
--SNIPPED ANOTHER DOZEN LINES-- --no-config -W-USE_BEFORE_DEF Project1.dpr
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:00.12
So as a result of all this, we've identified USE_BEFORE_DEF as the warning name for W1036 for use with the command line compiler, as well as illustrated exactly how to supply it to the compiler.
You can, of course, disable more than one warning in order to identify them; I've just used one for simplicity, and snipped out a lot of the command-line output that is produced.
I am debugging a problem with programmatically adding constraints. When my app crashes LLDB tells me to break on -[UIView _viewHierarchyUnpreparedForConstraint:] to debug the problem further. However, when I add a breakpoint with LLDB :
b s -n -[UIView _viewHierarchyUnpreparedForConstraint:]
I get the following warning from LLDB:
WARNING: Unable to resolve breakpoint to any actual locations.
I also tried adding a symbolic breakpoint using the Breakpoint navigator + option.
So it looks to me as if this symbol does not exist.
How can i see a list of all the symbols generated in order to make sure that this symbol exists or not?
thanks for your help
-Malena
The lldb command line is space-delimited, so if you want to pass arguments or option values to it that have spaces in them, you need to use quotes to protect the spaces. See if this works:
(lldb) b s -n "-[UIView _viewHierarchyUnpreparedForConstraint:]"
The careful reader would have noted that the command as you typed it had "-[UIView" as the option value for -n and then a dangling argument "_viewHierarchyUnpreparedForConstraint:]" and by rights (since break set takes no arguments) you should have gotten an error about break set taking no arguments. THAT is a bug...
To answer your other question, the lldb command:
(lldb) image dump symtab
will dump all the symbols in the program. You can scope this to a particular library by adding it to the command line, so for instance this one is probably in UIKit, so:
(lldb) image dump symtab UIKit
will show you only the symbols in UIKit. There's also a command to lookup particular symbols by name, image lookup -n though in general if the breakpoint setter can't find them, image lookup isn't going to find them either.
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.