[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

5. Debugging with RHIDE

For debugging your programs you need now no external debugger, because RHIDE has one integrated. The integrated debugger is not code which I have written, but it is GDB 4.16, which is linked in RHIDE.

Because RHIDE uses a special method to communicate with GDB it is currently not possible to use all of the features, which GDB has. I have implemented at this time the most important functions, which are needed to debug your program. So it is not possible to give GDB the same commands as when running GDB stand alone. That means, if you need any very special feature of GDB you must run GDB.

The integrated debugger is a real source level debugger like GDB. If you step through your program you will see every time exactly where in the sources you are. But to use the ability to debug your program needs, that you have compiled your source files with debugging information and these symbols must not have been stripped from the executable.

5.1 Limitations of the integrated debugger  
5.2 Dual display debugging  
5.3 Using the integrated debugger  
5.4 Problems with C++ programs  
5.5 Using Breakpoints  


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

5.1 Limitations of the integrated debugger

Because the integrated debugger is GDB, you will have all the limitations which GDB has in addition to well known DJGPP and/or MS-DOS limitations. Here is a (not complete) list of known misfeatures:


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

5.2 Dual display debugging

RHIDE supports now also to use an installed dual display. This is when you have installed in addition to your VGA card a monochrome display card together with a monitor. RHIDE checks this by asking the BIOS if it is present and if this is true and the option is enabled see section 3.9.6.3 Preferences then RHIDE switches automatically to the secondary display when debugging and your program will run on the primary display.

With this debugging technique you will get the best debugging results especially when debugging graphics programs.

To use the dual display with RHGDB use the `-D' switch for RHGDB.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

5.3 Using the integrated debugger

If you are familiar with Borland's debugger, you will see, that most of the functions of that debugger are implemented in the same or in a similar way (this includes the key bindings).

5.3.1 Stepping through the source code  
5.3.2 Evaluating the contents of variables  
5.3.3 Watching the contents of variables  


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

5.3.1 Stepping through the source code

For stepping through your code, there are three ways. This is at first the Step-function F8. With this you execute a complete source line. If there is a function call at the current execution point, this function is called without debugging it. This technique is the same like the `next'-command from GDB.

The next way is the Trace-function. It is like the Step-function, F7, except that if there is a function call at the current execution point, you will go into this function when there is debugging information for that function available. This technique is the same as the `step'-command from GDB.

And the third way is the Goto-Cursor-function. For this, move the cursor to the line in your source code and press F4. Now the execution of your program is continued until it comes to that line. Sometimes you will get an error message, that for the specified line is no code generated. This comes from the optimization of your code by GCC. In this case try a line below or above.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

5.3.2 Evaluating the contents of variables

You can evaluate also the the contents of variables, when your program has been started. For this you can press Ctrl+F4 and you will see a dialog, where you can type in the expression to evaluate, a line with the result and a line, where you can give the expression a new value. If you have pressed this in an editor window, RHIDE tries to find the word under the cursor and copies this as default in the expression input line. To get the contents of this expression you have to press the Evaluate-button.

If the expression could not be evaluated so it is shown in the result line. For the exact syntax of getting the contents of an expression see section `Expressions' in gdb. You can also show the value of the expression in several formats see section `Output Formats' in gdb.

In addition to the functionality of the Borland debuggers, GDB (and of course also RHIDE) can evaluate the result of function calls. If you have, for example, in your debugged program a function
 
int foo(int arg1)
{
/* do something and return a value */
}
defined, you can type in the expression input line
 
foo(16)
and you will get as result, what the function would return, if it is called with the argument 16. As arguments you can also use any known variable or complex expressions.

A known limitation is, that the expressions are NOT checked for validity. That means, you can produce any exception there, which will terminate your program. As an example type in the expression input line
 
3/0
And, of course, you cannot assign to a function call a new value.

As an special side effect you can use this also as a calculator. You can evaluate any trivial or complex expression and this is also available, if you haven't started the integrated debugger.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

5.3.3 Watching the contents of variables

In addition to a single look at the contents of a variable, you can add the variable to a list which is updated after each debugger step and is shown in the watching window. For this function you can use the hotkey Ctrl+F7.

Within the watch window you can press Enter on an expression to change that expression (NOT the contents of that expression) or you can press Del to remove the variable from the watch window.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

5.4 Problems with C++ programs

Because GDB cannot handle correctly C++ debugging information when it is generated as COFF debugging information (with stabs debugging information there is no such limitation and you can skip reading more) you will have many problems when debugging C++ programs to get the contents of a variable when it is a member of a class. Because GDB does not detect, that your program is a C++ program, it sees it as a normal C program and so GDB does nothing know about classes and all what have to do with it.

For accessing the member of a baseclass you must do some tricks. Let me explain it on an example:

 
class A
{
public:
  int a;
};

class B : public A
{
public:
  void test();
};

void B::test()
{
  fprintf(stdout,"%d\n",a);
}

If you debug the program in the function B::test() and you want to get the contents of the member a, you have to access it with this->A.a !!! That means: At first you must access all members with the implicit this variable and at second you must give all baseclasses until that, where the member was declared.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

5.5 Using Breakpoints

Breakpoints are a very useful thing when debugging a program. You can set a breakpoint at any location of your program and run it. It will be automatically stopped, if the program execution reaches the breakpoint.

5.5.1 Setting a breakpoint  
5.5.2 Modifying and setting a breakpoint  
5.5.3 Problems with breakpoints  


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

5.5.1 Setting a breakpoint

For setting a breakpoint there are two different ways. The first is by setting a breakpoint at any line by pressing Ctrl+F8. You will see, that there is a breakpoint set, that this line is shown in another color. If you hit Ctrl+F8 on a line, which has already a breakpoint, the breakpoint at this line is removed.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

5.5.2 Modifying and setting a breakpoint

The second way is by setting a breakpoint with the breakpoint dialog which is selectable only from the menu. There you will see any breakpoint for your program. These breakpoints can be modified now in many things. In this dialog you can enable/disable a breakpoint. This is not the same as deleting and resetting it. If you disable a breakpoint, it is stored internally but it is not used. If you enable it again all the settings for that breakpoint, which you have already made, are remembered.

In the breakpoint dialog you can also set or delete a breakpoint with the given buttons. If you want to set a new breakpoint, use the New-Button. Then you will get a dialog which you also get when you press the Modify-Button. In this dialog you can change many things of the breakpoint.

In this dialog is the only point for setting a breakpoint at a specified function. For doing this you must set at first the type of the breakpoint to Function. Then you can type in the function input line the name of the function or hit Ctrl+F1 to get a list of functions which are available from where you can select one with Enter.

For setting a breakpoint at a specified line, set the breakpoint type to Line and type in the filename and the linenumber.

The next what you can modify on a breakpoint is a condition. That means that the breakpoint should stop your program only, if the condition is true. Write the condition in the programming language of your source file and you can use any accessible variable and you can call also functions of the debugged program. For other information about the syntax see section `Conditions' in gdb.

And at last you can give your breakpoints also a count. A breakpoint count is a number, how often this breakpoint is ignored. That means, if you type there, for example, 10, then the RHIDE stops the execution of the program only, if it comes to that point the tenth time. WARNING: This count is set by RHIDE only once. After the breakpoint is really hit, from now on the breakpoint stops your program every time, the breakpoint is reached.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

5.5.3 Problems with breakpoints

Currently there is a big problem, when you have set a breakpoint at a line (not at a function) of your program and you edit now the source code. If you insert or delete some lines the breakpoints, which are set at lines after or at the modified lines are NOT updated to the correct line number.


[ << ] [ >> ]           [Top] [Contents] [Index] [ ? ]

This document was generated by Robert Hoehne on February, 16 2003 using texi2html