## gdb TUI mode debugging

June 9, 2016 C/C++ development and debugging. , , ,

I recently watched Greg Law’s “I’ll change your opinion on GDB” talk from CPPCON 2015, where he gave a nice example of how to use the gdb TUI (text user interface) mode. I’d recently encountered the gdb –tui option, but thought that you had to have the foresight to remember to invoke gdb with –tui (which I usually didn’t, but also didn’t always want to since it’s redraw was flaky in a putty terminal session).

It turns out that there are command line keystrokes to enable TUI dynamically when you want it (or turn it off when you don’t). That makes this TUI a much nicer feature!

The main key commands of interest are:

– C-x a, turn on (or off) TUI mode.
– C-x 2. Use two windows, or cycle to the next layout.
– C-x o. Change active window.
– C-L.  Redraw screen.
– C-x p. command history (since up and down move the cursor)

Here’s an example how things look after turning on TUI (C-x a):

After turning on two window mode (C-X 2):

This has a source view, an assembly view, and the output of ‘info registers’.  You can actually get a register window by cycling through the window layouts once (C-x 2 again) :

Some of the previous times that I’d tried ‘gdb –tui’ explicitly, I’d found it hit redraw issues, but didn’t really want to detach and reattach the debugger just to change the TUI mode.  It sounds like such issues can be dealt with either by turning off TUI mode (C-x a), or using redraw (C-L).

## Notes for Stroustrup’s “The C++ Programming Language, 4th Ed.”: nothrow new, noexcept, noreturn, static cons, initializer_list

I recently purchased Stroustrup’s C++11 book [1], after borrowing it a number of times from the Markham public library (it’s very popular, and only offered for short term loan) . Here are some notes of some bits and pieces that were new to me for this round of reading.

## nothrow new

In DB2 we used to have to compile with -fcheck-new or similar, because we had lots of code that predated new throwing on error (c++98). There is a form of new that explicitly doesn’t throw:

void * operator new( size_t sz, const nothrow_t &) noexcept ;


I don’t know if this was introduced in c++11. If this was a c++98 addition, then it should be used in almost all the codebases new calls. When I left DB2 there were still some platform compilers (i.e. AIX xlC which doesn’t use the clang front end like linuxppcle64 xlC) that were not c++11 capable, so if this explicit nothrow isn’t c++98, it probably can’t be used.

## Unnamed function parameters

It is common to see function prototypes without named parameters, such as

void foo( int, int ) ;


I did not realize that is also possible in the function definition, as in code like the following where a parameter has been dropped or left as a placeholder for future use

void foo( int x, int )
{
printf( "%d\n", x ) ;
}


Not naming the parameter is probably a good way to get rid of unused parameter warnings.

This is very likely not a c++11 addition. I just didn’t realize the language allowed for it, and had never seen it done.

## No return attribute

Looks like __attribute__ extensions are being baked right into the language, as in

[[noreturn]] void exit( int ) ;


I wonder if this is also in the plan for C?

C++11 explicitly requires static variable constructors are initialized using a “call-once” mechanism

class x
{
public:
x() ;
} ;

void foo( void )
{
static x v() ;
}


Here there is no data race if foo() is executed concurrently in a number of threads. I remember seeing DB2 code that did this (and opening a defect to have it “fixed”), since I had no idea if it would work. We didn’t (and couldn’t yet) use -std=c++11, so it’s anybody’s guess what that does without that option and on older pre c++11 compilers.

## Implied type initializer lists.

In a previous post I mentioned the c++11 uniform initialization syntax, but the basic idea is that is instead of

int x(1) ;
int y(0) ;


or

int x = 1 ;
int y = 0 ;


c++11 now allows

int x{1} ;
int y{} ;


Here the variables are initialized with values 1, and 0 (the default). The motivation for this was to provide an initializer syntax that could be used with container classes. Here’s another variation on the initializer list initialization

int x = int{} ;
int y = int{3} ;


which can be reduced to

int x = {} ;
int y = {3} ;


where the types of the lists are implied. I don’t see much value add to use this equals-list syntax in the examples above. Where this might be useful is in templated code to provide defaults

template <typename T>
void foo( T x, T v = {} ) ;


## Runtime values for default arguments.

I don’t know if this is new to C++11, but the book points out that default arguments can be runtime determined values. Initially, my thought on this was that it is good that is not well known, since it would be confusing. I did however, come up with a scenerio where this could be useful. I wrote some code like the following the other day

extern bool g ;

inline int foo( )
{
int res = 0 ;

if ( g )
{
// first option
}
else
{
// second option
}

return res ;
}


The global g was precomputed at the shared library startup point (effectively const without being marked so). My unit test of this code modified the value of g, which was a hack and I admit ugly. It looked like

BOOST_AUTO_TEST_CASE( basicTest )
{
for ( auto b : {false, true} )
{
g = b ;

int res = foo() ;

BOOST_REQUIRE( res >= 0 ) ;
}
}


This has a side effect of potentially changing the global. A different way to do this would have been

extern bool g ;

inline int foo( bool internalOverrideOfGlobalForTesting = g )
{
int res = 0 ;

if ( internalOverrideOfGlobalForTesting )
{
// first option
}
else
{
// second option
}

return res ;
}


The test code could then be rewritten as

BOOST_AUTO_TEST_CASE( basicTest )
{
for ( auto b : {false, true} )
{
int res = foo( b ) ;

BOOST_REQUIRE( res >= 0 ) ;
}
}


This doesn’t touch the global (an internal value), but still would have allowed for testing both codepaths. The fact that this “feature” exists may not actually be in this case, since my interface was a C interface. Does a

## noexcept

Functions that intend to provide a C interface can use the noexcept keyword. That allows the compiler to enforce the fact that such functions should provide a firewall that doesn’t let any exceptions through. Example:

// foo.h
#if defined __cplusplus
#define EXTERNC extern "C"
#define NOEXCEPT noexcept
#else
#define EXTERNC
#define NOEXCEPT
#endif

EXTERNC void foo(void) NOEXCEPT ;

// foo.cc
#include "foo.h"
int foo( void ) NOEXCEPT
{
int rc = 0 ;
try {
//
}
catch ( ... )
{
// handle error
rc = 1 ;
}

return rc ;
}


If foo does not catch all exceptions, then the use of noexcept will drive std::terminate(), like a throw from a destructor does on some platforms.

# References

[1] Bjarne Stroustrup. The C++ Programming Language, 4th Edition. Addison-Wesley, 2014.

## Integer square root

In [1] is a rather mysterious looking constant expression formula for an integer square root. This is a function that returns the smallest integer for which the square is less than the value to take the root of. Check out the black magic he used

// Stroustrup 10.4:  constexpr capable integer square root function
constexpr int isqrt_helper( int sq, int d, int n )
{
return sq <= n ? isqrt_helper( sq + d, d + 2, n ) : d ;
}

constexpr int isqrt( int n )
{
return isqrt_helper( 1, 3, n )/2 - 1 ;
}


The point of this construction was really to illustrate that it allows complex expressions to be used as compile time constants. I wonder at what point various compilers will give up trying to evaluate such expressions?

## Let’s take this apart a bit.

Consider the first few values of $$n > 0$$.

• $$n = 0$$. Here we have a call to $$\textrm{isqrt_helper}( 1, 3, 0 )$$ so the $$1 \le 0$$ predicate is false, and the return value is just $$3$$.

For that value we have (using integer arithmetic):

\label{eqn:isqrt:20}
\frac{3}{2} – 1 = 0,

as desired.

• $$n = 1$$. Here we have a call to $$\textrm{isqrt_helper}( 1, 3, 1 )$$ so the $$1 \le 1$$ predicate is true, resulting in a second call $$\textrm{isqrt_helper}( 4, 5, 1 )$$. For that call the $$4 \le 1$$ predicate is false, resulting in a return value of $$5$$.

This time we have a final result of

\label{eqn:isqrt:40}
\frac{5}{2} – 1 = 1,

as desired again. The result will be the same for any value $$n \in [1,3]$$.

• $$n = 4$$. We will end up with a call to $$\textrm{isqrt_helper}( 4, 5, 4 )$$ for which the $$4 \le 4$$ predicate is true, resulting in a followup call of $$\textrm{isqrt_helper}( 9, 7, 4 )$$. For that call the $$9 \le 4$$ predicate is false, resulting in a return value of $$7$$.

This time we have a final result of

\label{eqn:isqrt:45}
\frac{7}{2} – 1 = 2,

as expected. We get the same result for any value $$n \in [4,8]$$.

## Recurrence relations

The rough pattern of the magic involved can be seen. We have a sequence of calls

• $$\textrm{isqrt_helper}( 1, 3, n )$$,
• $$\textrm{isqrt_helper}( 4, 5, n )$$,
• $$\textrm{isqrt_helper}( 9, 7, n )$$,
• $$\textrm{isqrt_helper}( 16, 9, n )$$,

which terminates at the point where the first (square) parameter exceeds that value that we are taking the root of. Let the parameters of the sequence of calls be $$s_k$$, and $$d_k$$, so that with $$s_0 = 1, d_0 = 3$$ the $$k \in [0,…]$$ call to the helper function is $$q_k = \textrm{isqrt_helper}( s_k, d_k, n )$$.

The sequence for the second parameter, the eventual return value, can be summarized compactly as $$d_k = 3 + 2 k$$. It is not entirely obvious how we end up with a square for the values $$s_k = s_{k-1} + d_{k-1}$$, but this follows by summation. For $$k > 1$$ that is

\label{eqn:isqrt:60}
\begin{aligned}
s_k
&= s_{k-1} + d_{k-1} \\
&= s_0 + d_0 + d_1 + d_{k-1} \\
&= s_0 + \sum_{m=0}^{k-1} d_m \\
&= s_0 + \sum_{m=0}^{k-1} (3 + 2 m ) \\
&= s_0 + \sum_{m=1}^{k} (3 + 2 (m-1) ) \\
&= s_0 + \sum_{m=1}^{k} (1 + 2 m ) \\
&= 1 + k + 2 \sum_{m=1}^{k} m \\
&= 1 + k + 2 \frac{k(k+1)}{2} \\
&= k^2 + 2 k + 1 \\
&= (k+1)^2.
\end{aligned}

This clearly holds for the boundary cases $$k = 0,1$$ as well. This allows the helper function action to be summarized more compactly

\label{eqn:isqrt:80}
\textrm{isqrt_helper}(1, 3, n) = 3 + 2 k,

where $$k$$ is the smallest integer such that $$(k+1)^2 > n$$. After integer scaling the final result is

\label{eqn:isqrt:100}
(3 + 2 k)/2 -1 = k.

This little beastie makes sense after deconstruction, but it was very Jackson like to toss this into the book without comment or explanation.

As pointed out by Pramod Gupta, there’s a spooky appearance of collaboration between Stroustrup and Jackson’s publishers, not entirely limited to the book covers.

# References

[1] Bjarne Stroustrup. The C++ Programming Language, 4th Edition. Addison-Wesley, 2014.