| 1 | \chapter{Extending GDB for \uC}
|
|---|
| 2 |
|
|---|
| 3 | \section{Introduction}
|
|---|
| 4 | A sequential program has a single call stack. A debugger knows about this call stack and provides
|
|---|
| 5 | commands to walk up/down the call frames to examine the values of local variables, as well as global
|
|---|
| 6 | variables. A concurrent program has multiple call stacks (for coroutines/tasks), so a debugger must
|
|---|
| 7 | be extended to locate these stacks for examination, similar to a sequential stack. For example,
|
|---|
| 8 | when a concurrent program deadlocks, looking at the task's call stack can locate the resource and
|
|---|
| 9 | the blocking cycle that resulted in the deadlock. Hence, it is very useful to display the call stack
|
|---|
| 10 | of each task to know where it is executing and what values it is currently computing. Because each
|
|---|
| 11 | programming language's concurrency is different, GDB has to be specifically extended for \uC.
|
|---|
| 12 |
|
|---|
| 13 | \section{Design Constraints}
|
|---|
| 14 | As mentioned in Chapter \ref{GDB}, there are several ways to extend GDB. However, there are a few
|
|---|
| 15 | design constraints on the selected mechanism. All the functions implemented should maintain similar
|
|---|
| 16 | functionality to existing GDB commands. In addition to functional requirements, usability and
|
|---|
| 17 | flexibility are requirements for this project. These final requirements enable developers to be
|
|---|
| 18 | productive quickly and do more with the extensions. The extensions created for \uC are simple to use
|
|---|
| 19 | and versatile.
|
|---|
| 20 |
|
|---|
| 21 | The following new GDB command are all implemented through the Python API for GDB. Python is a
|
|---|
| 22 | scripting language with built-in data structures and functions that enables the development of more
|
|---|
| 23 | complex operations and saves time on development.
|
|---|
| 24 |
|
|---|
| 25 | \section{\uC source-code example}
|
|---|
| 26 | Listing \ref{uC-src-code} shows a \uC program that implicitly creates two clusters, system and user,
|
|---|
| 27 | which implicitly have a processor (kernel thread) and processor task. The program explicitly creates
|
|---|
| 28 | three additional processors and ten tasks on the user cluster.
|
|---|
| 29 |
|
|---|
| 30 | \begin{figure}
|
|---|
| 31 | \begin{lstlisting}[numbers=left, xleftmargin=4.0ex, style=C++, caption={\uC source code used for GDB commands},label={uC-src-code}, basicstyle=\small]
|
|---|
| 32 | _Task T {
|
|---|
| 33 | const int tid;
|
|---|
| 34 | std::string name;
|
|---|
| 35 |
|
|---|
| 36 | void f(int param) {
|
|---|
| 37 | if ( param != 0 ) f( param - 1 ); // recursion
|
|---|
| 38 | for ( volatile size_t i = 0; i < 100000000; i += 1 ); // delay
|
|---|
| 39 | int x = 3;
|
|---|
| 40 | std::string y = "example";
|
|---|
| 41 | } // breakpoint
|
|---|
| 42 | void main() {
|
|---|
| 43 | if ( tid != 0 ) // T0 goes first
|
|---|
| 44 | for ( volatile size_t i = 0; i < 1000000000; i += 1 ) // delay
|
|---|
| 45 | if ( i % 10000000 == 0 ) yield(); // execute other tasks
|
|---|
| 46 | f(3);
|
|---|
| 47 | }
|
|---|
| 48 | public:
|
|---|
| 49 | T(const int tid) : tid( tid ) {
|
|---|
| 50 | name = "T" + std::to_string(tid);
|
|---|
| 51 | setName(name.c_str());
|
|---|
| 52 | }
|
|---|
| 53 | };
|
|---|
| 54 | int main() {
|
|---|
| 55 | uProcessor procs[3]; // extra processors
|
|---|
| 56 | const int numTasks = 10;
|
|---|
| 57 | T * tasks[numTasks]; // extra tasks
|
|---|
| 58 | // allocate tasks with different names
|
|---|
| 59 | for (int id = 0; id < numTasks; id += 1) {
|
|---|
| 60 | tasks[id] = new T(id);
|
|---|
| 61 | }
|
|---|
| 62 | // deallocate tasks
|
|---|
| 63 | for (int id = 0; id < numTasks; id += 1) {
|
|---|
| 64 | delete tasks[id];
|
|---|
| 65 | }
|
|---|
| 66 | }
|
|---|
| 67 | \end{lstlisting}
|
|---|
| 68 | \end{figure}
|
|---|
| 69 |
|
|---|
| 70 | \section{Existing User-defined GDB Commands}
|
|---|
| 71 | Listing \ref{uC-callstack} shows the GDB output at the base case of the recursion for one of the
|
|---|
| 72 | tasks created in the \uC program in listing \ref{uC-src-code}. The task is stopped at line 10. The
|
|---|
| 73 | backtrace shows the three calls to function \verb|f|, started in the task's \verb|main|. The top two
|
|---|
| 74 | frames (5 and 6) are administrative frames from \uC. The values of the argument and local variables
|
|---|
| 75 | are printed.
|
|---|
| 76 | \begin{lstlisting}[caption={Call stack of function \texttt{a} in the \uC
|
|---|
| 77 | program from listing \ref{uC-src-code}}, label={uC-callstack}, basicstyle=\small\tt]
|
|---|
| 78 | (gdb) backtrace
|
|---|
| 79 | #0 T::f (this=0xa4f950, param=0) at test.cc:10
|
|---|
| 80 | #1 0x000000000041e509 in T::f (this=0xa4f950, param=1) at test.cc:6
|
|---|
| 81 | #2 0x000000000041e509 in T::f (this=0xa4f950, param=2) at test.cc:6
|
|---|
| 82 | #3 0x000000000041e509 in T::f (this=0xa4f950, param=3) at test.cc:6
|
|---|
| 83 | #4 0x000000000041e654 in T::main (this=0xa4f950) at test.cc:15
|
|---|
| 84 | #5 0x0000000000428de2 in ...::invokeTask (This=...) at ...
|
|---|
| 85 | #6 0x0000000000000000 in ?? ()
|
|---|
| 86 | (gdb) info args
|
|---|
| 87 | this = 0xa4f950
|
|---|
| 88 | param = 0
|
|---|
| 89 | (gdb) info locals
|
|---|
| 90 | x = 3
|
|---|
| 91 | y = "example"
|
|---|
| 92 | \end{lstlisting}
|
|---|
| 93 |
|
|---|
| 94 | \subsection{Listing all clusters in a \uC program}
|
|---|
| 95 | Listing \ref{clusters-command} shows the new command \verb|clusters| to list all program clusters
|
|---|
| 96 | along with their associated address. The output shows the two \uC implicitly created clusters.
|
|---|
| 97 | \begin{lstlisting}[caption={clusters command}, label={clusters-command}, basicstyle=\small\tt]
|
|---|
| 98 | (gdb) clusters
|
|---|
| 99 | Name Address
|
|---|
| 100 | systemCluster 0x65a300
|
|---|
| 101 | userCluster 0x7ca300
|
|---|
| 102 | \end{lstlisting}
|
|---|
| 103 |
|
|---|
| 104 | \subsection{Listing all processors in a cluster}
|
|---|
| 105 | Listing \ref{cluster-procs} shows the new command \verb|processors|, which requires a cluster
|
|---|
| 106 | argument to show all the processors in that cluster. In particular, this example shows that there
|
|---|
| 107 | are four processors in the \verb|userCluster|, with their associated address, PID, preemption and
|
|---|
| 108 | spin.
|
|---|
| 109 | \begin{lstlisting}[caption={processors command}, label={cluster-procs}, basicstyle=\small\tt]
|
|---|
| 110 | (gdb) processors
|
|---|
| 111 | Address PID Preemption Spin
|
|---|
| 112 | 0x7ccc30 8421504 10 1000
|
|---|
| 113 | 0x8c9b50 9478272 10 1000
|
|---|
| 114 | 0x8c9d10 10002560 10 1000
|
|---|
| 115 | 0x8c9ed0 10530944 10 1000
|
|---|
| 116 | \end{lstlisting}
|
|---|
| 117 |
|
|---|
| 118 | \subsection{Listing all tasks in all clusters}
|
|---|
| 119 | Listing \ref{tasks} shows the new command \verb|task| with the \verb|all| argument to list all the
|
|---|
| 120 | tasks in a \uC program at this point in the execution snapshot. The internal \uC threads
|
|---|
| 121 | (implicitly created) are numbered with negative identifiers, while those created by the application
|
|---|
| 122 | are numbered with zero/positive. The \verb|*| indicates the \uC thread (\verb|T0|) that encountered
|
|---|
| 123 | the breakpoint at line 10. GDB stops all execution and the states of the other threads are ready,
|
|---|
| 124 | running, or blocked. If the argument \verb|all| is removed, only internal information about the
|
|---|
| 125 | \verb|userCluster| and its implicitly created threads is printed, which is sufficient for most
|
|---|
| 126 | applications.
|
|---|
| 127 | \begin{lstlisting}[caption={task command for displaying all tasks for all clusters}, label={tasks}, basicstyle=\footnotesize\tt]
|
|---|
| 128 | (gdb) task all
|
|---|
| 129 | Cluster Name Address
|
|---|
| 130 | systemCluster 0x65a300
|
|---|
| 131 | ID Task Name Address State
|
|---|
| 132 | -1 uProcessorTask 0x6c99c0 uBaseTask::Blocked
|
|---|
| 133 | -2 uSystemTask 0x789f40 uBaseTask::Blocked
|
|---|
| 134 | userCluster 0x7ca300
|
|---|
| 135 | ID Task Name Address State
|
|---|
| 136 | -1 uProcessorTask 0x80ced0 uBaseTask::Blocked
|
|---|
| 137 | -2 uBootTask 0x659dd0 uBaseTask::Blocked
|
|---|
| 138 | 0 main 0x7fffffffe490 uBaseTask::Blocked
|
|---|
| 139 | -3 uProcessorTask 0x90e810 uBaseTask::Blocked
|
|---|
| 140 | -4 uProcessorTask 0x98ee00 uBaseTask::Blocked
|
|---|
| 141 | -5 uProcessorTask 0xa0f3f0 uBaseTask::Blocked
|
|---|
| 142 | * 1 T0 0xa4f950 uBaseTask::Running
|
|---|
| 143 | 2 T1 0xa8fce0 uBaseTask::Running
|
|---|
| 144 | 3 T2 0xad0070 uBaseTask::Running
|
|---|
| 145 | 4 T3 0xb10400 uBaseTask::Ready
|
|---|
| 146 | 5 T4 0xb50790 uBaseTask::Ready
|
|---|
| 147 | 6 T5 0xb90b20 uBaseTask::Ready
|
|---|
| 148 | 7 T6 0xbd0eb0 uBaseTask::Ready
|
|---|
| 149 | 8 T7 0xc11240 uBaseTask::Ready
|
|---|
| 150 | 9 T8 0xc515d0 uBaseTask::Running
|
|---|
| 151 | 10 T9 0xc91960 uBaseTask::Ready
|
|---|
| 152 | \end{lstlisting}
|
|---|
| 153 |
|
|---|
| 154 | \subsection{Listing all tasks in a cluster}
|
|---|
| 155 | Listing \ref{cluster-tasks} shows the new command \verb|task| with a cluster argument to list only
|
|---|
| 156 | the names of the tasks on that cluster. In this version of the command \verb|task|, the associated
|
|---|
| 157 | address for each task and its state is displayed.
|
|---|
| 158 | \begin{lstlisting}[caption={task command for displaying all tasks in a cluster}, label={cluster-tasks}, basicstyle=\small\tt]
|
|---|
| 159 | (gdb) task systemCluster
|
|---|
| 160 | ID Task Name Address State
|
|---|
| 161 | -1 uProcessorTask 0x6c99c0 uBaseTask::Blocked
|
|---|
| 162 | -2 uSystemTask 0x789f40 uBaseTask::Blocked
|
|---|
| 163 | \end{lstlisting}
|
|---|
| 164 |
|
|---|
| 165 | \section{Changing Stacks}
|
|---|
| 166 | The next extension for displaying information is writing new commands that allow stepping from one
|
|---|
| 167 | \uC task to another. Each switching remembers the task tour in a LIFO way. This semantics means push
|
|---|
| 168 | and pop commands are needed. The push is performed by the \verb|task| command with a task argument.
|
|---|
| 169 | The pop is performed by the new command \verb|prevtask| or shorthand \verb|prev|.
|
|---|
| 170 |
|
|---|
| 171 | \subsection{Task Switching}
|
|---|
| 172 | The task argument for pushing is a relative id within a cluster or absolute address on any
|
|---|
| 173 | cluster. For instance, to switch from any task to task \verb|T2| seen in listing \ref{tasks}, the
|
|---|
| 174 | first command in listing \ref{task-addr-arguments} uses relative id (3) implicitly from the
|
|---|
| 175 | \verb|userCluster|, the second command uses an absolute address (\verb|0xad0070|), and the third
|
|---|
| 176 | command uses relative id (3) with the explicit \verb|userCluster|. Core functionality of these
|
|---|
| 177 | approaches is the same. Finally, the \verb|prevtask| command is used to unwind the stack until it is
|
|---|
| 178 | empty.
|
|---|
| 179 | \begin{lstlisting}[caption={task command arguments}, label={task-addr-arguments}, basicstyle=\small\tt]
|
|---|
| 180 | (gdb) task 3
|
|---|
| 181 | (gdb) task 0xad0070
|
|---|
| 182 | (gdb) task 3 userCluster
|
|---|
| 183 | (gdb) prevtask
|
|---|
| 184 | ...
|
|---|
| 185 | (gdb) prev
|
|---|
| 186 | ...
|
|---|
| 187 | (gdb) prev
|
|---|
| 188 | ...
|
|---|
| 189 | (gdb) prev
|
|---|
| 190 | empty stack
|
|---|
| 191 | \end{lstlisting}
|
|---|
| 192 |
|
|---|
| 193 |
|
|---|
| 194 | \subsection{Switching Implementation}
|
|---|
| 195 | To implement the task tour, it is necessary to store the context information for every context
|
|---|
| 196 | switching. This requirement means the \verb|task| command needs to store this information every time
|
|---|
| 197 | it is invoked.
|
|---|
| 198 |
|
|---|
| 199 | \begin{figure}
|
|---|
| 200 | \centering
|
|---|
| 201 | \includegraphics[width=8cm]{uContext_stack}
|
|---|
| 202 | \caption{Machine context (uMachContext) for each task}
|
|---|
| 203 | \label{machine-context}
|
|---|
| 204 |
|
|---|
| 205 | \vspace*{0.5in}
|
|---|
| 206 |
|
|---|
| 207 | \begin{lstlisting}[style=Python, caption={Abridged \texttt{push\_task} source code}, label={pushtask-code}, basicstyle=\small\tt]
|
|---|
| 208 | # get GDB type of uContext_t *
|
|---|
| 209 | uContext_t_ptr_type = gdb.lookup_type('UPP::uMachContext::uContext_t').pointer()
|
|---|
| 210 |
|
|---|
| 211 | # retrieve the context object from a task and cast it to the type uContext_t *
|
|---|
| 212 | task_context = task['context'].cast(uContext_t_ptr_type)
|
|---|
| 213 |
|
|---|
| 214 | # the offset where sp would be starting from uSwitch function
|
|---|
| 215 | sp_address_offset = 48
|
|---|
| 216 | # lookup the value of stack pointer (sp), frame pointer (fp),
|
|---|
| 217 | # program counter (pc)
|
|---|
| 218 | xsp = task_context['SP'] + sp_address_offset
|
|---|
| 219 | xfp = task_context['FP']
|
|---|
| 220 | if not gdb.lookup_symbol('uSwitch'):
|
|---|
| 221 | print('uSwitch symbol is unavailable')
|
|---|
| 222 | return
|
|---|
| 223 |
|
|---|
| 224 | # This value is calculated here because we always here when the task is in
|
|---|
| 225 | # blocked state
|
|---|
| 226 | xpc = get_addr(gdb.parse_and_eval('uSwitch').address + 28)
|
|---|
| 227 | # must switch back to frame-0 to set 'pc' register with the value of xpc
|
|---|
| 228 | gdb.execute('select-frame 0')
|
|---|
| 229 |
|
|---|
| 230 | # retrieve register values and push sp, fp, pc into a global stack
|
|---|
| 231 | global STACK
|
|---|
| 232 | sp = gdb.parse_and_eval('$sp')
|
|---|
| 233 | fp = gdb.parse_and_eval('$fp')
|
|---|
| 234 | pc = gdb.parse_and_eval('$pc')
|
|---|
| 235 | stack_info = StackInfo(sp = sp, fp = fp, pc = pc)
|
|---|
| 236 | STACK.append(stack_info)
|
|---|
| 237 |
|
|---|
| 238 | # update registers for new task
|
|---|
| 239 | gdb.execute('set $rsp={}'.format(xsp))
|
|---|
| 240 | gdb.execute('set $rbp={}'.format(xfp))
|
|---|
| 241 | gdb.execute('set $pc={}'.format(xpc))
|
|---|
| 242 | \end{lstlisting}
|
|---|
| 243 | \end{figure}
|
|---|
| 244 |
|
|---|
| 245 | Figure \ref{machine-context} shows a task points to a structure containing a \verb|uContext_t| data
|
|---|
| 246 | structure, storing the stack and frame pointer, and the stack pointer. Listing \ref{pushtask-code}
|
|---|
| 247 | shows these pointers are copied into an instance of the Python tuple \verb|StackInfo| for every
|
|---|
| 248 | level of task switching. This tuple also stores information about the program counter that is
|
|---|
| 249 | calculated from the address of the \verb|uSwitch| assembly function because a task always stops in
|
|---|
| 250 | \verb|uSwitch| when its state is blocked. Similarly, switching commands retrieve this context
|
|---|
| 251 | information but from the task that a user wants to switch to, and sets the equivalent registers to
|
|---|
| 252 | the new values.
|
|---|
| 253 |
|
|---|
| 254 | To push using the \verb|task| command, the value of the hardware stack pointer \verb|rsp| register,
|
|---|
| 255 | frame pointer \verb|rbp| register, and program counter register \verb|pc| are copied from the
|
|---|
| 256 | blocked task's save-area to the Python stack. To pop using the \verb|prevtask| command, the three
|
|---|
| 257 | registers are moved from the Python stack to the appropriate hardware registers. Popping an empty
|
|---|
| 258 | stack prints a warning.
|
|---|
| 259 |
|
|---|
| 260 | Note, for tasks running when a breakpoint is encountered, the task's save-area is out-of-date; i.e.,
|
|---|
| 261 | the save area is only updated on a context switch, and a running task's stack represents the current
|
|---|
| 262 | unstored state for that task, which will be stored at the next context switch. Hence, to examine
|
|---|
| 263 | running tasks, it is necessary to use the GDB \verb|info threads| and \verb|thread| commands to
|
|---|
| 264 | examine and then step onto running tasks.
|
|---|
| 265 |
|
|---|
| 266 | Listing \ref{rr-tasks} shows how to examine ready and running tasks. Task \verb|T3| is ready (see
|
|---|
| 267 | Listing \ref{tasks}) because it was forced to context switch because of a time-slice preemption.
|
|---|
| 268 | Switching to \verb|T3|, which is relative id 4, and listing its the backtrace (stack frames) shows
|
|---|
| 269 | frames 0--6, which are the execution sequence for a time-slice preemption (and can be ignored), and
|
|---|
| 270 | frames 7--9, which are the frames at the point of preemption. Frame 7 shows \verb|T3| is at line 14
|
|---|
| 271 | in the test program (see Listing \ref{uC-src-code}). Switching to running task \verb|T1|, which is
|
|---|
| 272 | relative id 2 (see Listing \ref{tasks}), and listing its backtrace shows a similar backtrace to
|
|---|
| 273 | ready task \verb|T3|. However, this backtrace contains stale information. The GDB command
|
|---|
| 274 | \verb|info threads| shows the status of each kernel thread in the application, which represents the
|
|---|
| 275 | true location of each running thread. By observation, it can be seen that thread 2 is executing task
|
|---|
| 276 | \verb|0xa8fce0|, which is task \verb|T1|. Switching to kernel thread 2 via GDB command
|
|---|
| 277 | \verb|thread 2| and listing its backtrace show that task \verb|T1| is current executing at line 13
|
|---|
| 278 | in the test program.
|
|---|
| 279 |
|
|---|
| 280 | \begin{figure}
|
|---|
| 281 | \begin{lstlisting}[numbers=left, xleftmargin=3.0ex, caption={Examine ready/running tasks}, label={rr-tasks}, basicstyle=\footnotesize\tt]
|
|---|
| 282 | (gdb) task 4
|
|---|
| 283 | #0 T::f (this=0xa4f950, param=0) at test.cc:10
|
|---|
| 284 | (gdb) backtrace
|
|---|
| 285 | #0 uSwitch () at /u0/usystem/software/u++-7.0.0/src/kernel/uSwitch-x86_64.S:64
|
|---|
| 286 | #1 0x000000000042bd5c in uBaseCoroutine::taskCxtSw (this=0x8c9d28) ...
|
|---|
| 287 | #2 0x000000000042fff4 in UPP::uProcessorKernel::scheduleInternal ...
|
|---|
| 288 | #3 0x000000000042d4b6 in uBaseTask::uYieldInvoluntary ...
|
|---|
| 289 | #4 0x000000000042172f in uKernelModule::rollForward ...
|
|---|
| 290 | #5 0x000000000042f4fe in UPP::uSigHandlerModule::sigAlrmHandler ...
|
|---|
| 291 | #6 <signal handler called>
|
|---|
| 292 | #7 0x000000000041e620 in T::main (`this=0xb10400`) at test.cc:14
|
|---|
| 293 | #8 0x0000000000428de2 in UPP::uMachContext::invokeTask (This=...) ...
|
|---|
| 294 | #9 0x0000000000000000 in ?? ()
|
|---|
| 295 | (gdb) task 2
|
|---|
| 296 | (gdb) backtrace
|
|---|
| 297 | #0 uSwitch () at /u0/usystem/software/u++-7.0.0/src/kernel/uSwitch-x86_64.S:64
|
|---|
| 298 | #1 0x000000000042bd70 in uBaseCoroutine::taskCxtSw (this=0x8c9b68) ...
|
|---|
| 299 | #2 0x000000000042fff4 in UPP::uProcessorKernel::scheduleInternal ...
|
|---|
| 300 | #3 0x000000000042d4b6 in uBaseTask::uYieldInvoluntary ...
|
|---|
| 301 | #4 0x000000000042172f in uKernelModule::rollForward ...
|
|---|
| 302 | #5 0x000000000042f50c in UPP::uSigHandlerModule::sigAlrmHandler ...
|
|---|
| 303 | #6 <signal handler called>
|
|---|
| 304 | #7 0x000000000041e620 in T::main (`this=0xa8fce0`) at test.cc:14
|
|---|
| 305 | #8 0x0000000000428de2 in UPP::uMachContext::invokeTask (This=...) ...
|
|---|
| 306 | #9 0x0000000000000000 in ?? ()
|
|---|
| 307 | (gdb) info threads
|
|---|
| 308 | Id Target Id Frame
|
|---|
| 309 | 1 Thread 0x7ffff7fc8780 (LWP 7425) "a.out" 0x00007ffff6d74826 in ...
|
|---|
| 310 | 2 Thread 0x808080 (LWP 7923) "a.out" 0x41e5fc in T::main `(this=0xa8fce0`) at test.cc:13
|
|---|
| 311 | * 3 Thread 0x90a080 (LWP 7926) "a.out" uSwitch () ...
|
|---|
| 312 | 4 Thread 0x98a080 (LWP 7929) "a.out" T::main (this=0xad0070) at test.cc:14
|
|---|
| 313 | 5 Thread 0xa0b080 (LWP 7931) "a.out" 0x41e629 in T::main (this=0xc515d0) at test.cc:14
|
|---|
| 314 | (gdb) thread 2
|
|---|
| 315 | #1 0x000000000041e509 in T::f (this=0xa4f950, param=1) at test.cc:6
|
|---|
| 316 | 6 if ( param != 0 ) f( param - 1 ); // recursion
|
|---|
| 317 | [Switching to thread 2 (Thread 0x808080 (LWP 7923))]
|
|---|
| 318 | #0 0x000000000041e5fc in T::main (`this=0xa8fce0`) at test.cc:13
|
|---|
| 319 | 13 for ( volatile size_t i = 0; i < 1000000000; i += 1 ) // delay
|
|---|
| 320 | (gdb) backtrace
|
|---|
| 321 | #0 0x000000000041e5fc in T::main (`this=0xa8fce0`) at test.cc:13
|
|---|
| 322 | #1 0x0000000000428de2 in UPP::uMachContext::invokeTask (This=...) ...
|
|---|
| 323 | #2 0x0000000000000000 in ?? ()
|
|---|
| 324 | \end{lstlisting}
|
|---|
| 325 | \end{figure}
|
|---|
| 326 |
|
|---|
| 327 | \subsection{Continuing Implementation}
|
|---|
| 328 | When a breakpoint or error is encountered, all concurrent execution stops. The state of the program
|
|---|
| 329 | can now be examined and changed; after which the program may be continued. Continuation must always
|
|---|
| 330 | occur from the top of the stack (current call) for each task, and at the specific task where GDB
|
|---|
| 331 | stopped execution.
|
|---|
| 332 |
|
|---|
| 333 | However, during a task tour, the new GDB commands change the notion of the task where execution
|
|---|
| 334 | stopped to make it possible to walk other stacks. Hence, it is a requirement for continuation that
|
|---|
| 335 | the task walk always return to frame-0 of the original stopped task before any program continuation
|
|---|
| 336 | \cite{Reference11}.
|
|---|
| 337 |
|
|---|
| 338 | % For every new function call, a new stack frame is created and the values of all the registers are
|
|---|
| 339 | % changed for that frame. Therefore, in order to see the true value of hardware registers, innermost
|
|---|
| 340 | % frame that is frame-0 must be selected \cite{Reference11}. However, it is possible to not be in
|
|---|
| 341 | % frame-0, so prior to setting these values, the command must switch back to the innermost
|
|---|
| 342 | % (currently executing) frame first.
|
|---|
| 343 |
|
|---|
| 344 | To provide for this requirement, the original stop task is implicitly remembered, and there is a new
|
|---|
| 345 | \verb|reset| command that \emph{must} be explicitly executed before any continuation to restore the
|
|---|
| 346 | locate state. To prevent errors from forgetting to call the \verb|reset| command, additional hooks
|
|---|
| 347 | are added to the existing built-in GDB continuation commands to implicitly call \verb|reset|. The
|
|---|
| 348 | following list of these commands results from GDB documentation \cite{Reference15} and similar work
|
|---|
| 349 | done for KOS \cite{Reference14}.
|
|---|
| 350 | \begin{lstlisting}[caption={Built-in GDB commands that allow continuation of a program}, label={continue-cmds}, basicstyle=\small\tt]
|
|---|
| 351 | continue,next,nexti,step,stepi,finish,advance,jump,signal,until,run,thread,
|
|---|
| 352 | reverse-next,reverse-step,reverse-stepi,reverse-continue,reverse-finish
|
|---|
| 353 | \end{lstlisting}
|
|---|
| 354 |
|
|---|
| 355 | % These hooks call a new command called \verb|reset| prior to executing the command to enable
|
|---|
| 356 | % continuation of a program to ensure that the program's context is automatically switched back to
|
|---|
| 357 | % the context of the task that initiates the first context switch. The \verb|reset| command behaves
|
|---|
| 358 | % as same as the command \verb|prevtask|, however, it goes back directly to where the task is when
|
|---|
| 359 | % the program last stops, which is the first task in the task tour.
|
|---|
| 360 |
|
|---|
| 361 | \section{Result}
|
|---|
| 362 | The current implementation successfully allows users to display a snapshot of \uC execution with
|
|---|
| 363 | respect to clusters, processors, and tasks. With this information it is possible to tour the call
|
|---|
| 364 | stacks of the tasks to see execution locations and data values. Additionally, users are allowed to
|
|---|
| 365 | continue the execution where the program last pauses assuming that the program has not crashed. The
|
|---|
| 366 | continuation of execution is done by automatically reversing the task walk from any existing GDB
|
|---|
| 367 | commands such as \verb|continue|, or a user can manually reverse the task walk using the command
|
|---|
| 368 | \verb|prevtask| and then continue.
|
|---|
