GNU debugger - adapteva/epiphany-sdk GitHub Wiki
The GDB and e-server have now been extended to allow a single connection to the Epiphany target, with each core appearing as a thread.
Starting e-server
Only a single instance of e-server is now needed on the Parallella board
e-server
Note that e-server now runs in user mode and no longer requires EPIPHANY_HOME to be set. The default port is 51000, but an alternative can be specified using the -p flag:
e-server -p 52000
For a full list of all the e-server options, use:
e-server --help
Connecting with GDB
From within GDB connect to the single port. Suppose my Parallella is on IP address 10.42.0.21, with e-server running on its default port 51000. Then to start debugging a simple program (in this example hello), use:
e-gdb hello
<lots of messages>
(gdb) target remote 10.42.0.21:51000
All the threads can be seen using info threads
(gdb) info threads
[New Thread 102]
[New Thread 103]
[New Thread 104]
[New Thread 201]
[New Thread 202]
[New Thread 203]
[New Thread 204]
[New Thread 301]
[New Thread 302]
[New Thread 303]
[New Thread 304]
[New Thread 401]
[New Thread 402]
[New Thread 403]
[New Thread 404]
Id Target Id Frame
16 Thread 404 (Core: 0303: halted, interruptible) 0x0000023a in main ()
at hello.c:7
15 Thread 403 (Core: 0302: halted, interruptible) 0x00000000 in start ()
14 Thread 402 (Core: 0301: halted, interruptible) 0x00000000 in start ()
13 Thread 401 (Core: 0300: halted, interruptible) 0x00000000 in start ()
12 Thread 304 (Core: 0203: halted, interruptible) 0x0000023a in main ()
at hello.c:7
11 Thread 303 (Core: 0202: halted, interruptible) 0x00000000 in start ()
10 Thread 302 (Core: 0201: halted, interruptible) 0x00000000 in start ()
9 Thread 301 (Core: 0200: halted, interruptible) 0x0000023a in main ()
at hello.c:7
8 Thread 204 (Core: 0103: halted, interruptible) 0x00000000 in start ()
7 Thread 203 (Core: 0102: halted, interruptible) 0x00000000 in start ()
6 Thread 202 (Core: 0101: halted, interruptible) 0x00000000 in start ()
5 Thread 201 (Core: 0100: halted, interruptible) 0x00000000 in start ()
4 Thread 104 (Core: 0003: halted, interruptible) 0x00000000 in start ()
3 Thread 103 (Core: 0002: halted, interruptible) 0x00000000 in start ()
2 Thread 102 (Core: 0001: halted, interruptible) 0x00000000 in start ()
* 1 Thread 101 (Core: 0000: halted, interruptible) main () at hello.c:12
(gdb)
Note that each thread has its own thread ID, which is computed as:
(100 * (core row + 1)) + core_column + 1
GDB will allocate a thread number in sequence to each thread, but info threads allows you to see what core each connects to.
GDB and running programs
GDB currently works in "all-stop" mode (we are working on a "non-stop" version). This means that when it gains control, each thread is halted. However the processor is not reset, so if any cores have code already running that code will be halted, but can then be resumed. This can be seen in this example, where I am connecting to a system which has previously been running the hello program on some cores.
This is a change from the previous version of GDB, which reset each core on connection.
Manipulating threads
You can select a thread with the thread command. For example
(gdb) thread 5
(gdb) thread 5
[Switching to thread 5 (Thread 201)]
#0 0x00000000 in start ()
All the standard GDB commands work. For example I could if I use the load command, it will load the program onto thread 5 (which is core 0100 in this example).
(gdb) load
Loading section ivt_reset, size 0x4 lma 0x0
Loading section .reserved_crt0, size 0xc lma 0x58
Loading section .init, size 0x24 lma 0x64
Loading section .text, size 0x20c lma 0x90
Loading section .fini, size 0x1a lma 0x29c
Loading section .ctors, size 0x8 lma 0x2b8
Loading section .dtors, size 0x8 lma 0x2c0
Loading section .jcr, size 0x4 lma 0x2c8
Loading section .data, size 0x4 lma 0x2cc
Loading section .rodata, size 0x8 lma 0x2d0
Loading section NEW_LIB_RO, size 0x174 lma 0x8e000000
Loading section NEW_LIB_WR, size 0x454 lma 0x8e000174
Loading section GNU_C_BUILTIN_LIB_RO, size 0x6 lma 0x8e0005c8
Start address 0x0, load size 2120
Transfer rate: 159 KB/sec, 151 bytes/write.
(gdb)
Breakpoints, stopping and starting
There is a slight problem with modeling Parallella cores as threads. Standard threads share a single address space. This is largely for Parallella, except that each cores bottom 1MB of address space is local to that core. There are multiple instances of a program, not one shared image. This means that GDB breakpoints, which should apply to all threads will not behave as expected, if the address is in local memory.
e-server solves this by silently setting a breakpoint on all threads whenever a breakpoint is requested.
Feedback
The new version of GDB attempts to meet the challenges of debugging on Parallella, and it represents quite an extension of standard GDB behaviour. Feeback from users on how it can be improved is much appreciated.