From 5fbf99bcc4d03f3001f42905d1217758c4aeac13 Mon Sep 17 00:00:00 2001 From: Timothy Pearson Date: Wed, 16 Nov 2011 16:06:07 -0600 Subject: Finish rename from prior commit --- doc/kdevelop/debugger.docbook | 242 ------------------------------------------ 1 file changed, 242 deletions(-) delete mode 100644 doc/kdevelop/debugger.docbook (limited to 'doc/kdevelop/debugger.docbook') diff --git a/doc/kdevelop/debugger.docbook b/doc/kdevelop/debugger.docbook deleted file mode 100644 index 247d26ff..00000000 --- a/doc/kdevelop/debugger.docbook +++ /dev/null @@ -1,242 +0,0 @@ - -The Debugger Interface -debugger - - -For C and C++, &tdevelop; contains an internal debugger that is directly -integrated with the editor. Technically, it is implemented as a frontend -that uses the portable &GNU; debugger gdb through -a pipe. The debugger can be started in several ways: - - - - - -With DebugStart, -the main program of your project is loaded into the debugger. - - - - - -Using Debug -Start (other) -Examine core file you load a core file -into memory, which is generated by the operating system kernel when the -program has crashed (The generation of core files may be switched off on your -system, see ulimit(1)). This is useful for a -post-mortem analysis of a program. - - - - - -With Debug -Start (other) -Attach to process you invoke the -debugger on an already running program. You will be shown a -process list where you can select the process which the debugger -should take over. - - - - - -Note that debugging is only possible if your project has been compiled with -debugging information enabled. It can be activated in the -Compiler options dialog. When this option is switched -on, the compiler generates additional data which allows the debugger to -associate file names and line numbers with addresses in the executable. - - - - - -The debugger frontend offers several views into the process: - - -If you try to debug a project without debugging information, you get -the message No source... in the status -bar.If you try to set a breakpoint, it is shown as Pending -(add) in the breakpoint window (see below). - - - - -Variables - -watch variables - -This window lists the values of all local variables at the current execution -point of the program. It covers the variables in the complete call stack, -&ie; the function where the process was interrupted, the function that called -this function, and so on up to main() function. - - - -Another branch in the variables contains watch variables. You can configure -yourself which variables are shown here. Both local and global variables can -be watched. You can add variables either by clicking on the -Add button or pressing Return while -the Watch item is selected. They can be removed again -via the context menu. - - - - - -Frame Stack - -frame stack - -(... to be written ...) - - - - - -Breakpoints - -breakpoints - -This window allows you to see and manipulate the breakpoints. Remember that -&tdevelop; uses GDB, so to fully understand the -&tdevelop; debugging features, you should know a little bit about the GDB. - - -If you want to look at the source code, breakpoints are defined in -tdevelop/languages/cpp/debugger/breakpoint.h. - - -At the left edge, the window has buttons to: - - -Add an empty breakpoint -Edit the selected breakpoint - Delete the selected breakpoint -Remove all breakpoints - - -The main part of the window is a table with 7 columns. Each line in -the table is a breakpoint. The columns are: - - -Selection checkbox -Type: one of: Invalid, File:Line, Watchpoint, Address, Function -Status. Values are: - - Active - Disabled: Each breakpoint may be enabled or - disabled; if disabled, it has no effect on your program until - you enable it again. - Pending (add): a breakpoint is marked like this if no - debugging information is available. From GDB Info page: -
If a specified breakpoint location cannot be found, it may be due to - the fact that the location is in a shared library that is yet to be - loaded. In such a case, you may want GDB to create a special - breakpoint (known as a pending breakpoint) that attempts to resolve - itself in the future when an appropriate shared library gets loaded. -
- - - -Pending (clear) -Pending (modify) -Location in the format filename:linenumber -Condition -Ignore Count: If this is a number COUNT -greater than zero, the next COUNT times the breakpoint is -reached, your program's execution does not stop; other than to decrement the -ignore count, gdb takes no action. -Hits: counts how many times a breakopint has been hit. - - - - - - - -Disassemble - -disassemble -(... to be written ...) - - - - - - - -Setting Breakpoints - - -(... to be written ...) - - - - - - - -Options - - - -Display Mangled Names - -name mangling -manglingname - - -In C++, function names in the executable are mangled, &ie; -the function names include information about the argument types. This is -necessary in order to support overloading of functions. The mangling -algorithm is not standardized and differs even between different versions of -the &GNU; C++ compiler. - - - -In the disassembling window, normally unmangled names are displayed, so -function signatures appear in the similar way as in the source code, so -they are easily readable. Alternatively, you can decide to see mangled names. - - - - - -Try Setting Breakpoints on Lib Load - -lazy breakpoints -breakpointslazy - - -The debugger backend gdb does not allow to set -breakpoints within code that is not currently loaded. In a highly modular -application, where often code is only loaded on demand as a plugin (using -the libc function dlopen(3)), this can be inconvenient. -Therefore, &tdevelop; rolls its own support for breakpoints in shared -libraries. If you set this option, it allows you to set breakpoints in -libraries which are not loaded. Then, whenever gdb -notifies that a library is loaded, &tdevelop; tries to set the pending -breakpoints. - - - - - -Enable Floating Toolbar - -debugger toolbar -toolbardebugger - - -(... to be written ...) - - - - - - - - -- cgit v1.2.3