Toggle between -O2 and -O0, which is the default non-optimized compilation.
In my definition, A “simple assignment” is one without using functions. It can get value from another variable or a literal. Simple assignments are optimized away under -O2, so gdb cannot stop on these lines. This applies to break point or step-through.
In particular, if you breakpoint on a simple assignment then “info breakpoint” will show a growing hit count on this breakpoint, but under -O2 gdb would never stop there. -O0 works as expected.
As another illustration, if an if-block contains nothing but simple assignment, then gdb has nowhere to stop inside it and will only stop after the if-block. You won’t know whether you entered it. -O0 works as expected.
After you enter that command, next screen prompts you for commit message and lists files affected but the list is unfiltered! If some or all of the files are unchanged, the actual commit will skip them.
worked for me, 1024 is the array size in bytes
I tried various color schemes. None worked, so I found “monochrome with bold” pretty decent:
<to be elaborated>
So that’s the fall-back option. Now here’s one color scheme that might produce readable color on white background. In this case I turned on all the settings under Windows->colors:
- tick AllowTerminaltoSpecifyAnsiColors
- tick AllowTerminalToUseXterm256
- tick AttempToUseLogicalPalettes
- tick UseSysColors
- radio group choose Both
Imperfection: I get yellow text on white background 😦
Whenever you turn on color support in terminal and in q(grep), you open a can of worm. Often LESS would need -R switch to cope with “ESC[01”
gitignore can be investigated. Git can tell you why a particular file is ignore. CVS doesn’t support that instrumentation.
If you need to confirm a file is explicitly ignored, then you can put a single “!” in ~/.cvsignore (as described in the official manual) to clear the ignore list.
gdb $base/shared/tp_xtap/bin/xtap ~/nx_parser/core
### 1st arg is the executable responsible for the core dump. If this executable is correct, then you should not get “No symbol table is loaded. Use the file command.” If you do, then try
(gdb) file /path/to/xtap
I think “symbol” means the variable/function names. I think gdb sees only … address not names. To translate them, presumably you need *that* file.
In my case the “xtap” executable is a debug-build, verified with “file” and “objdump” commands, according to http://stackoverflow.com/questions/3284112/how-to-check-if-program-was-compiled-with-debug-symbols
Anyway, once the symbols are loaded, you should run “bt” to load the back trace (gdb) bt
Now choose one of the frames such as the 2nd most recent function i.e. Frame #1 (gdb) frame 1
Now gdb shows the exact line number and the line of source code. You can see before/after lines with “list”. Those lines may belong to other functions collocating in the same source file. (gdb) list