cvs update/checkout a file or dir

–cvs update a dir or file:

cvs update –dA package/aida/common/script Bring working dir specified up to date with the repository (merge changes made to the repository into the local files).
cvs update –A package/aida/common/script/MakefileAida.sun4
Bring just the named file up-to-date with the repository

–cvs checkout a dir or file:

cvs checkout edu Checks out everything under edu, placing an edu directory, plus all subordinate subdirectories, in the working dir.
cvs checkout app/alh Checks out everything under app/alh placing an app directory in your working directory, but only the alh subdirectory of app.
cvs co package/aida/common/script/MakefileAida.sun4
Checks out only the single file MakefileAida.sun4, creating package/aida/common/script/MakefileAida.sun4 in the working directory, containing that one file.

q(g++ -g -O) together

https://linux.die.net/man/1/g++ has a section specifically on debugging. It says

GCC allows you to use -g with -O

I think -g adds additional debug info into the binary to help debuggers; -O turns on complier optimization.

By default, our binaries are compiled with “-g3 -O2”. When I debug these binaries, I can see variables but lines are rearranged in source code, causing minor problems. See my blog posts on gdb.

gdb q(next) over if/else +function calls #optimized

I used an optimized binary. Based on limited testing, un-optimized doesn’t suffer from these complexities.

Conventional wisdom: q(next) differs from q(step) and should not go into a function

Rule (simple case): When you are on a line of if-statement in a source code, q(next) would evaluate this condition. If the condition doesn’t involve any function call, then debugger would evaluate it and move to the “presumed next line”, hopefully another simple statement.

Rule 1: suppose your “presumed next line” involves a function call, debugger would often show the first line in the function as the actual “pending”. This may look like step-into!

Eg: In the example below. Previous pending is showing L432 (See Rule 2b to interpret it). The presumed line is L434, but L434 involves a function call, so debugger actually shows L69 as the “pending” i.e. the first line in the function

Rule 2 (more tricky): suppose presumed line is an if-statement involving a function call. Debugger would show first line in the function as the pending.

Eg: In the example below, Previous pending was showing L424. Presumed line is L432, but we hit Rule 2, so actual pending is L176, i.e. first line in the function.

Rule 2b: when debugger shows such an if-statement as the “pending”, then probably the function call completed and debugger is going to evaluate the if-condition.

424 if (isSendingLevel1){
425 //……
426 //……….
427 //……..
428 //……….
429 } // end of if
430 } // end of an outer block
431
432 if (record->generateTopOfBook()
433 && depthDb->isTopOfTheBook(depthDataRecord)) {
434 record->addTopOfBookMarker(outMsg);
435 }

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”