| 72 | | It opens a gdb session. You can now run the model and interact with it while it runs. For instance, you can create ''break points'', which stop the run at a given point. **Be careful** : if you specify a break point at a given line of the code, it has to be the line number from the **compiled** version of the program! (.f or .f90, in LMDZ.COMMON/tmp_src/). |
| 73 | | |
| 74 | | You can then look at some variables via the ''print'' command, then continue the run. Here is an example below : |
| | 75 | It opens a gdb session. You can now run the model and interact with it while it runs. For instance, you can create ''break points'', which pause the run at a given point. You can then look at some variables via the ''print'' command, then continue the run. Here is an example below : |
| 112 | | Try {{{(gdb) print MODULENAME::VARNAME}}} if you want to print a variable (''VARNAME'') from another module (''MODULENAME'') that the subroutine is using. If you want to look at a variable saved in a Fortran ''COMMON'' block (ex: variables from the infamous ''callkeys.h''), doing {{{(gdb) info common}}} will print the value of all the variables from the ''COMMON'' blocks. |
| | 113 | Below, we give some more details on specific **gdb** commands. |
| | 114 | |
| | 115 | === Break points |
| | 116 | You can define break points by specifying a line where the program will pause : {{{(gdb) break PROGRAM_NAME:LINE_NB}}} |
| | 117 | **Careful** : if you specify a break point at a given line of the GCM code, it has to be the line number from the **pre-processed** version of the program ! (.f or .f90, in LMDZ.COMMON/tmp_src/). |
| | 118 | |
| | 119 | Break points also work by specifying a call to a function/subroutine : {{{(gdb) break SUBROUTINE_NAME}}} will pause the run when it encounters a {{{call SUBROUTINE_NAME}}}. It still enters the subroutine, which becomes the current context. If the subroutine is defined in a module, try {{{(gdb) break MODULE_NAME::SUBROUTINE_NAME}}} |
| | 120 | |
| | 121 | Break points can be defined before and during the {{{(gdb) run}}} (see the example above). |
| | 122 | |
| | 123 | === Watch points |
| | 124 | ''Watch points'' enables you to follow the state of a variable, by pausing the program when the value of this variable changes, and by displaying the change that has been done. You can set up a watch point via the command {{{(gdb) watch VAR_NAME}}}. |
| | 125 | |
| | 126 | **Careful** : you can set a watch point only on variables that have already been defined in your current context ! It can thus only be used after the {{{(gdb) run}}}, and usually requires to do a break point before in the subroutine (if you want to watch a local variable of this subroutine). |
| | 127 | |
| | 128 | === Print |
| | 129 | After you have stopped at some point in the code (thanks to a break or watch point for instance), you can print the value of variables. |
| | 130 | The syntax for printing variables that are defined in your current context (''ex:'' local variables or arguments of your subroutine) is simply {{{(gdb) print VAR_NAME}}} |
| | 131 | |
| | 132 | Try {{{(gdb) print MODULE_NAME::VAR_NAME}}} if you want to print a variable (''VAR_NAME'') from another module (''MODULE_NAME'') that the subroutine is using. |
| | 133 | |
| | 134 | If you want to look at a variable saved in a Fortran ''COMMON'' block (''ex:'' variables from the infamous ''callkeys.h''), doing {{{(gdb) info common}}} will print the value of all the variables from the ''COMMON'' blocks. |
| | 135 | |
| | 136 | ''NB:'' if you have stopped in a subroutine which is now your current context, you can go back to your main program (where you have the instruction {{{call SUBROUTINE_NAME}}}) and thus change the context thanks to the command {{{(gdb) up}}}. To go back in your subroutine, use {{{(gdb) down}}}. |
| | 137 | |
| | 138 | === List |
| | 139 | Pretty useful, the command {{{(gdb) list}}} displays the code line where you just stopped, as well as some of the lines that will come just after. |
| | 140 | |
| | 141 | Remember that when you pause at a given line, you haven't executed it yet ! (you're stopped at the beginning of the line) |
| | 142 | |
| | 143 | === Continue / Step |
| | 144 | After you have paused the run, you can resume running with the command {{{(gdb) continue}}} |
| | 145 | |
| | 146 | You can also just run the next line and pause again with the command {{{(gdb) step}}} |
| | 147 | |
| | 148 | === Debug in parallel |
| | 149 | If you want to do some debug while running in parallel, it should be possible to do a {{{mpirun gdb gcm_exec_debug.e}}}, which will run multiple instances of {{{gdb gcm_exec_debug.e}}} (one in each thread) that will still communicate and wait for each other when they need it (as when you run the model directly, in parallel). |
| | 150 | Note that this is a bit complicated and not so well tested among us. It may be better to use other tools, like **ddd** or **ddt** (though they are not installed on all machines). |
