|
|
None of the programs in this tutorial have code that comes from an included file, but having code in header files is a common situation, particularly in C++ programs, which frequently have numerous inline functions defined in header files or make use of templates, whose source may be included automatically by the compiler. Any statement that comes from a header file is displayed by the debugger in terms of both the compilation unit (or primary source file name) and the included file name, using the syntax compilation_unit@included_file. For example, given the following program:
process.c: #include <stdlib.h> #include "chdr.h" void process(char *str) { f(str); ... } chdr.h: static void f(char *str) { if (str == 0) return; ... }The location of the function f called by the function process is given by process.c@chdr.h@f. When you stop in that function, the location is displayed in the event notification and in the stack trace.
debug> stop process.c@chdr.h@f EVENT [1] assigned debug> run STOP EVENT TRIGGERED: f in p1 [f in process.c@chdr.h] 4: if (file == 0) debug> stack Stack Trace for p1, Program a.out *[0] f(str="testing") [process.c@chdr.h@4] [1] process(str="testing") [process.c@6] ...Also, although the source file displayed by list is from chdr.h, the debugger can only find chdr.h by looking through the debugging information generated for process.c. The debugger variables %file and %list_file reflect that condition:
debug> print %list_file "process.c@chdr.h"
This has several implications for you in setting breakpoints or in examining the source for code in included files:
debug> list process.c@chdr@1 1: static void 2: f(char *str) 3: ...
debug> dis chdr.h@4 File chdr.h was not found. Search program for an included file? debug> yes Disassembly for p1, Program a.out . . .
debug> stop chdr.h@4 Set a breakpoint on all occurrences of chdr.h@4? debug> yes EVENT [3] assigned