gdb stop@simple assignments #compiler optimize

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.

linux console color(putty): observations

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”

cvsignore troubleshoot`

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.

%%first core dump gdb session

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

cvs cheatsheet

–top 10 how-to

  1. list modified files — 2 choices
    1. cvs -qn up # shows both untracked and uncommitted
    2. cvs status |grep # doesn’t offer a quick glance
  2. list untracked files in the current dir (git clean -fxd) —
    1. cvs -qn up | grep ‘^?’  # listing only
  3. cvs (git reset –hard)
    1. cvs up -C the/file
  4. checkout a single dir/file. First, cd into the parent dir , then 2 choices
    1. cvs up -d missingDir
    2. cvs co tp/plugins/xtap/missingDir # no leading slash. See http://www.slac.stanford.edu/grp/cd/soft/cvs/cvs_cheatsheet.html for explanation

–Tier 2 (Still useful):

  • cvs -H any command
  • the -l option: -l Local; run only in top of current working directory, rather than recursing through subdirectories. Available with the following commands: checkout, diff, log, status, tag, update..