3-Simple Executive Debugger SE调试器

Contents

• 1 Introduction
• 2 Building Code for the Debugger
• 3 Running the Debugger on Octeon Hardware
• 4 Debugging via a terminal server
• 5 Running the Debugger on Octeon Simulator
• 6 Cavium Specific GDB Variables for Multicore Debugging
• 7 Other Cavium Specific GDB Variables
• 8 Multicore Breakpoints
• 9 Multicore Hardware Breakpoints
• 10 Hardware watchpoints
• 11 Multicore Performance Counters
• 12 Finding the cause of an exception with the debugger
• 13 Program Termination with Multiple Cores
• 14 The DDD Graphical Debugger
• 15 Running the Debugger - The manual way
• 15 Running the inter-core Debugger

1 Introduction

The Octeon Debugger (mipsisa64-octeon-elf-gdb) supports interactive control of programs running in the Octeon Simulator and in Octeon hardware. Any number of cores from 1 to 16 can be controlled through one interface.

octeon调试器(mipsisa64-octeon-elf-gdb)支持在octeon模拟器和octeon硬件中运行程序的支持交互式控制。从1到16中任何一个编号的核都能通过一个接口去控制。

2 Building Code for the Debugger

To debug a program, build the executable by passing "-O0 -g" options.

要调试一个程序，编译生成可执行文件时加上"-O0 -g" 选项。

    $ cd examples/debugger
    $ make

Although you can debug programs compiled with optimization (-O?), results will be problematic. Since the majority of the Octeon support code is implemented in inline functions, the compiler optimizations will make it just about impossible to determine the current stack frame and line number.

尽管你能调试用-O?选项编译的程序，结果可能是不确定的。因为大多数octeon支持的代码是用内联函数实现的，编译器的优化使得它无法确定当前的堆栈帧和行号。

3 Running the Debugger on Octeon Hardware  在Octeon硬件上运行调试器

The debugger communicates with Octeon Hardware through a serial port or over PCI or while running Linux. Refer 18. Debugging using GDB on how to debug application over PCI and 15 Running the inter-core Debugger for how to debug applications while running Linux.

A serial cable must be connected from Octeon board to your host machine for debugging.

调试器通过一个串口或者通过PCI或者运行linux与Octeon硬件通信。18. Debugging using GDB说明了如何去通过PCI调试应用程序，15 Running the inter-core Debugger说明了如何在运行linux的时候调试应用程序。

调试时必须用一条串口线将Octeon开发板和你的主机连起来。

Before invoking the debugger, the program should be loaded into Octeon memory. Run the program by passing debug option to "bootoct" command. The debug=? option will make the program enter into the debug exception handler where the cores keep waiting for the command from the debugger. debug= should be followed by the number of the Octeon uart to use for debugging. If it isn't supplied, the default is uart 1 (the second uart).

启用调试器之前，要将程序下载到octeon内存中。通过在"bootoct" 命令上加 debug选项运行这个程序。debug=? 的选项将使程序进入debug异常处理状态，此时处理器核将一直等待调试器发出的命令。“debug=”后面应该加上用于调试的octeon串口号，默认是用uart1（即第二个uart）。

   octeon ebt3000# bootoct 100000 coremask=3 debug=1

Now invoke the debugger using oct-debug (a shell wrapper function) on your host machine to debug the program.

现在启用调试器，使用你主机上的oct-debug（一个shell包装的函数）去调试程序。

   # oct-debug test.out /dev/ttyS0

Note:

When using a single uart for debugging and console, make sure you close any terminal programs before starting the debugger.

当使用一个uart去做调试口和控制口时，在开启调试器之前你要确定所有的终端程序都被关闭了。

Description of the options:

    test.out    The program to be debugged.
    /dev/ttyS0  The host device name for the serial port that is connected
                to uart1 of the Octeon board. This is configured as 115200,8,N.

When using the Octeon debugger directly, invoke the commands following the example below:

当直接使用octeon的调试器时，调用下面例子中的命令：

  # mipsisa64-octeon-elf-gdb
      GNU gdb 6.3
    Copyright 2004 Free Software Foundation, Inc.
    GDB is free software, covered by the GNU General Public License, and you are
    welcome to change it and/or distribute copies of it under certain conditions.
    Type "show copying" to see the conditions.
    There is absolutely no warranty for GDB.  Type "show warranty" for details.
    This GDB was configured as "--host=i686-pc-linux-gnu --target=mipsisa64-octeon-elf".
  (Core#0-gdb) file test.out
    Reading symbols from /usr/local/Cavium_Networks/OCTEON-SDK/examples/debugger/test.out...done.
  (Core#0-gdb) target octeon /dev/ttyS0
    Remote target octeon connected to /dev/ttyS0
  (Core#0-gdb) load

4 Debugging via a terminal server  通过一个终端服务器去调试

Connecting to the serial port through a terminal server is supported in GDB. When invoking the target command instead of specifying the serial device use the hostname of the terminal server and the port that routes to the debugger port on the board. For example:

GDB支持通过一个终端服务器去连接串口。当你不是指定串口设备，而是使用目标板的命令时，使用终端服务器的主机名和板子上路由到调试器的那个端口。例：

  (Core#0-gdb) target octeon tcp:terminal-server:3001
    Remote target octeon connected to tcp:terminal-server:3001

On some terminal servers there is no way to fully disable telnet negotiations. In this case the initial characters sent by GDB can be misinterpreted and taken for a negotiation response.

GDB prints the characters that cannot be interpreted according to the protocol. So the symptom is that instead of the above message there will be some garbage printed as a response to the target command and then nothing further will be printed.

在一些终端服务器上没有办法去完全禁止telnet的协商。在这种情况下的GDB最初发送的字符可能被误认并给出协商相应。

根据协议，GDB打印字符的动作不能被打断。所以出现的后果就是没有打印上面的信息，却打印了一些垃圾信息，作为对目标命令的响应，然后没有进一步的打印了。

In this case it can help to insert a delay before GDB sends the first packet. The variable transmit-delay holds the seconds how much time GDB should wait before sending the first packet:

在这种情况下，它能帮助在GDB发送第一个包之前插入一个延时。transmit-delay 变量存放了发送第一个包之后GDB应该等待多久才发第二个包。

  (Core#0-gdb) set transmit-delay 2
  (Core#0-gdb) target octeon tcp:terminal-server:3001
  {{}}Remote target octeon connected to tcp:terminal-server:3001
  (Core#0-gdb)

5 Running the Debugger on Octeon Simulator  在octeon模拟器上运行调试器

A shell wrapper script (oct-debug) has been supplied to simplify the starting of the debugger. This scripts is a drop in replacement for oct-sim. For example, to start the debugger example execute:

为简化调试器，octeon提供了一个shell包装的脚本 (oct-debug) 。这个脚本替换oct-sim的小程序。例如，要开启调试器示例执行：

    $ oct-debug test.out -quiet -noperf -numcores=2

Descriptions of the options:

    test.out    The program to be debugged.
    -quiet      Tell the simulator not to trace assembler instructions.
    -noperf     Don't perform cycle accurate timing. This isn't
                strictly necessary, but greatly speeds up debugging
                with large numbers of cores.
    -numcores=2 Specify the number of cores to simulate.

All other standard simulator options are supported. For a complete list execute oct-sim without any arguments.

其他所有的标准模拟器的选项都是支持的。一个完全的列表执行oct-sim，不带任何参数。

6 Cavium Specific GDB Variables for Multicore Debugging        用于多核调试的cavium专用GDB变量

Three GDB state variables control support for multicore debugging. These variables are "active-cores", "focus", and "step-all". The standard GDB set and show commands access these variables. A description of each variable's affect on the debugging environment is listed below:

三个GDB状态变量控制用于支持多核调试。 它们是"active-cores", "focus", 和 "step-all"。通过这些变量，标准GDB设置并显示命令。在调试环境下每个变量的作用描述如下：

• active-cores: This is a comma separated list of cores under active control of the debugger. Cores in this list will stop if any other core hits a breakpoint. Cores not in this list will only stop if they hit a breakpoint. Note that although cores not in active-cores do not stop when other cores hit a breakpoint, they do suffer a performance hit. As a convenience, setting the active cores to an empty string (set active-cores) is interpreted as setting all cores active.
• active-cores: 这是一个逗号分割的在调试器主动控制下处理器核的列表。如果任何其他的核运行到了一个断点，列表中的核都会停止。非列表中的核只会在它们自己运行到一个断点的时候才会停止。要知道，尽管其他核运行到一个断点时 非active-cores中的核不会停止，它们的性能将受到冲击。设置active核为空字符串（设置 active-cores）被解读成设置所有的核为 active 状态，这是一个便捷的方法。

        (Core#0-gdb) set active-cores 0,1
        (Core#0-gdb) show active-cores
        The cores stopped on execution of a breakpoint by another core is "0,1".
        (Core#0-gdb) set active-cores
        (Core#0-gdb) show active-cores
        The cores stopped on execution of a breakpoint by another core is
        "0,1,2,3,4,6,7,8,9,10,11,12,13,14,15".
        (Core#0-gdb)
    

• focus: This is the index (0-15) of the core directly interacting with the debugger. Data operations (r/w memory, registers) are performed in the focus cores context. Only cores currently stopped in a debug exception may become the focus core. This means making a non-active core the focus generally requires a breakpoint or changing the active-cores to include it. The GDB prompt will show the current focus core. Note that the focus core may change if another core hits a breakpoint. The core to hit a breakpoint first automatically becomes the focus core.
• focus:这是处理器核直接和调试器相互作用的索引号（0-15）。数据操作（读/写内存和寄存器）是在focus core的上下文中进行的。一般只有核在一个调试异常中停止时才可能成为focus core。这意味着要使一个非active核变成focus核通常需要一个断点或者修改 active-cores去包含它。GDB的提示信息将会显示当前的focus core。注意如果另外一个核运行到一个断点时，当前的focus core可能就改变了。第一个运行到断点的核将自动的成为focus core。

        (Core#0-gdb) show focus
        The focus core of debugger operations is 0.
        (Core#0-gdb) set focus 5

        Breakpoint 1, main () at test.c:62
        (Core#5-gdb) show focus
        The focus core of debugger operations is 5.
        (Core#5-gdb)
    

• step-all: This GDB variable controls the cores action when the commands step, step instruction, and continue are executed. By default (step-all off) only the focus core performs the operations. Execution of other cores occurs only if step-all is on. Note that cores not in the active-cores list currently stopped will continue execution under any step command with step-all enabled.
• step-all：这个GDB变量控制着单步、单条指令和继续执行的命令被执行时核的动作。默认（step-all关闭）时，只有focus core执行操作。只有setp-all打开的时候其他核才能执行操作。注意：当前处于停止状态的非active-cores列表中的核将在step-all打开时任何的单步命令下继续执行。

        (Core#5-gdb) show step-all
        Step commands affect all cores is off.
        (Core#5-gdb) set step-all on
        (Core#5-gdb) show step-all
        Step commands affect all cores is on.
        (Core#5-gdb)
    

Commonly, sets of cores perform various program tasks. When debugging, it can be helpful to stop only cores performing a specific task. These cores would be set in the active-cores list, allowing this task to be debugged while the other cores continue to operate normally.

通常，这些核的集合完成各种程序任务。当调试时，它可以帮助去停止执行某一特殊任务的那些核。这些核将被设置到active-cores列表中，使这个任务被调试而其他核继续正常运作。

7 Other Cavium Specific GDB Variables  其他cavium专用GDB变量

• spawn-sim: With the octeon target, GDB can internally spawn the simulator and run the program inside the simulator automatically. The simulator is spawned in a new terminal so that you can inspect its output. This mode is enabled by setting spawn-sim:
• spawn-sim：与octeon目标一起，GDB内部可以产生模拟器并自动地在这个模拟器中运行程序。这个模拟器是在一个新终端中产生的，因此你能检查它的输出。这个模式的使能由spawn-sim设置。

        (Core#0-gdb) file test.out
        (Core#0-gdb) set spawn-sim 1
        (Core#0-gdb) target octeon tcp::65259
        // new terminal is launched with the simulator
        Remote target octeon connected to tcp::1234
        (Core#0-gdb)
      

8 Multicore Breakpoints  多核断点

Break point inserted into the program using the GDB "break" command are implemented using Mips software break instructions. The instruction at the breakpoint is replaced with a "sdbbp" instruction. Once execution reaches this point, GDB will replace the "sdbbp" with the original program instruction. The breakpoint will not be reinserted until the core that hit the "sdbbp" steps past the breakpoint. This leaves a window where other cores may bypass the breakpoint without stopping. In order to avoid this hazard, the focus core must be stepped at least once with step-all off before any other cores are allowed to execute.

通过使用MIPS软件break指令，使用GDB "break"命令可以在程序中插入断点。断点处的指令已被一个"sdbbp"指定所替代。一旦运行到断点，GBD将"sdbbp"替换成最初的程序指令。断点将不会被重新插入，除非hit "sdbbp"的这个核跳过这个断点。这为其他核绕过这个断点而不停止打开了一扇窗。为了避免这个风险，focus core必须在step-all关闭且其他的任何核都没有被允许执行的情况下至少执行一步。

It is possible to have two or more cores hit a breakpoint on the same instruction cycle. If step-all doesn't appear to be working as you'd expect, make sure another core isn't continually hitting a breakpoint. A core cannot proceed past a breakpoint until it is stepped as the focus processor.

在同一个指令周期内两个或多个核hit到一个断点的情况是可能的。如果step-all不能像你所想的那样工作，请确保另外一个核没有重复的hit一个断点。处理器核不能越过断点继续执行，除非它是focus核。

9 Multicore Hardware Breakpoints  多核硬件断点

Hardware breakpoints are inserted into the program using the GDB "hbreak" command. Each core can have maximum of four hardware breakpoints. When "hbreak" command is issued at the debugger prompt, the hardware breakpoints is applied to the focused core.

插入硬件断点使用GDB "hbreak"命令。每个核可以用最多4个硬件断点。当调试提示中发出"hbreak"命令时，硬件断点就被应用到了focused core上。

10 Hardware watchpoints   硬件观察点

Octeon supports both read and write hardware watchpoints. Hardware watchpoints are inserted into the program using the GDB "watch", "rwatch" and "awatch" commands. There are maximum of four hardware watchpoints available per debugging section.

octeon同时支持读和写硬件观察点。硬件观察点通过GDB  "watch", "rwatch" 和 "awatch" 命令插入到程序中。每个调试段中最多可以有4个硬件观察点。

11 Multicore Performance Counters  多核性能计数器

Octeon supports two performance counter registers. Each performance counter can be enabled by specifying an event. To see the events supported for Octeon, invoke "set perf-event[0|1]" at the GDB prompt.

octeon提供了2个性能计数器寄存器。每个性能计数器通过指定一个事件去使能。要查看octeon支持的事件，在GDB提示下调用"set perf-event[0|1]"。

To initialize an event invoke "set perf-event[0|1] <event>" at GDB prompt.

在GDB提示下调用"set perf-event[0|1] <event>"去初始化一个事件。

At any point performance counter register values can be checked by invoking "show perf-event[0|1]" command at GDB prompt. When the performance counters are not initialized the counter is reset to zero.

任何时刻在GDB提示下调用"show perf-event[0|1]"命令可以查看性能计数器寄存器的值。当性能计数器没被初始化时，计数器被复位为0。

The performance counter events are applied to the focused core.

性能计数器事件是应用在focused core上的。

12 Finding the cause of an exception with the debugger   用调试器找到异常产生的原因

GDB can unwind the exception handler frame to the frame that has caused the exception. If you set a breakpoint on the default exception handler (__cvmx_interrupt_default_exception_handler) or on the custom handler you installed you can backtrace to the frame causing the exception.

GDB能展开异常处理帧到异常引起的帧。如果你在默认的异常处理句柄(__cvmx_interrupt_default_exception_handler) 或者你自定义的句柄上设了一个断点 ，你就能回溯到引起异常的frame了。

On hardware you can do this even without setting a breakpoint upfront. In the default exception handler that CVMX provides -- after dumping the register context and printing backtrace information -- the program enters an infinite loop. You can stop the program in this loop by hitting Ctrl-C on the GDB console and then examine the cause of the exception in detail.

硬件上你可以这样做即使你前期没有设置断点。在CVMX提供的默认异常处理句柄中，----在倾卸掉寄存器内容和打印出回溯信息之后，程序进入一个死循环。在GDB控制台下你可以按Ctrl-C停止这个死循环程序，而后检查出详细的引起异常的原因。

Here is an example when a breakpoint is set on __cvmx_interrupt_default_exception_handler.

下面是一个在__cvmx_interrupt_default_exception_handler上设断点的例子。

test.c:

#include <cvmx.h>
#include <unistd.h>

int *i = 0;  // causes exception

void foo (void)
{
  *i = 0;
}

void (*p) (void) = foo;

main ()
{
  cvmx_user_app_init ();
  p ();
  return 0;
}

Compile the above simple executive program and invoke the debugger for debugging.

编译上述SE程序并用调试器调试。

mipsisa64-octeon-elf-gdb -q test.out
(Core#0-gdb) target octeon tcp::65258
Remote target octeon connected to tcp::65258
(Core#0-gdb) b __cvmx_interrupt_default_exception_handler
Breakpoint 1 at 0x10005d18: file /usr/local/Cavium_Networks/OCTEON-SDK/executive/cvmx-interrupt.c, line 549.
(Core#0-gdb) break main
Breakpoint 2 at 0x100002f0: file test.c, line 15.
(Core#0-gdb) run
Starting program: /home/cchavva/work/sdk-base/sdk/examples/debugger/test.out

Breakpoint 2, main () at test.c:15
15        cvmx_user_app_init ();
(Core#0-gdb) continue
Continuing.

Breakpoint 1, __cvmx_interrupt_default_exception_handler (registers=0x160ffed8)
    at /home/cchavva/work/sdk-base/sdk/executive/cvmx-interrupt.c:321
321         ebt3000_str_write("Trap");
(Core#0-gdb) backtrace
#0  __cvmx_interrupt_default_exception_handler (registers=0x160ffed8)
    at /home/cchavva/work/sdk-base/sdk/executive/cvmx-interrupt.c:321
#1  0x100075b0 in cvmx_interrupt_stage2 ()
    at /usr/local/Cavium_Networks/OCTEON-SDK/executive/cvmx-interrupt-handler.S:266
#2  0x100002dc in foo () at test.c:8
#3  0x10000304 in main () at test.c:16
(Core#0-gdb) up
#1  0x10007528 in cvmx_interrupt_stage2 ()
    at /usr/local/Cavium_Networks/OCTEON-SDK/executive/cvmx-interrupt-handler.S:266
266             dadd    a0, sp, 0       // First argument is array of registers
Current language:  auto; currently asm
(Core#0-gdb) up
#2  0x100002dc in foo () at test.c:8
8         *i = 0;
Current language:  auto; currently c
(Core#0-gdb) print i
$1 = (int *) 0x0

13 Program Termination with Multiple Cores   多核的程序终止

As far as the debugger is concerned, program termination occurs when all cores complete execution and returns control to the debugger. Any shutdown synchronization desired must be implemented as part of the program.

就与相关调试器而言，当所有的核完成了执行程序并将控制权返回给调试器时，程序终止发生了。任何关机同步所要做的工作都必须作为程序的一部分来实现。

14 The DDD Graphical Debugger    DDD图形调试

The Octeon SDK provides a multicore capable version of DDD (mipsisa64-octeon-elf-ddd). It is executed automatically by oct-debug to provide a graphical interface for debugging. The default setup provides new command buttons for quick focus and step-all changes. Documentation for DDD can be found at:

http://www./software/ddd/

Octeon SDK 提供了一个有多核能力的DDD版本 (mipsisa64-octeon-elf-ddd)。它由oct-debug 自动执行以提供一个图形化的接口用于调试。默认的设置提供了新的命令按钮用于focus和setp-all的快速改变。DDD的文档在：http://www./software/ddd/

15 Running the Debugger - The manual way   运行调试器-----手动方式

As is the nature of debugging, sometimes you need something unsupported by the oct-debug wrapper script. Here are the minimal steps to start the Octeon debugger.

由于调试的性质，有时你需要一些未被the oct-debug脚本提供的东西。这些开始octeon调试器的最小步骤。

1) Startup two terminal interfaces to the machine. One will be the debugger terminal, the other will be the simulator terminal. The simulator terminal will only be used to see output from the program under debug control while the debugger terminal will require interactive input.

1)给机器启动两个终端接口。一个用做调试器终端，另一个用作模拟器终端。模拟器终端只是用来察看在调试控制下程序的输出，而调试器终端用来作交互式输入。

2) In the simulator terminal: Start the program as normal except for an additional two arguments. The parameter "-uart1=65258" will allow communications through TCP port 65258. The second parameter "-debug" tells the simulator to stop before starting main and wait for the debugger. The program should then pause with all processors stopped. Here is the example output for reference:

2)在模拟器终端：和平常一样开始运行程序，除了要加两个参数之外。一个参数"-uart1=65258" 将允许通过TCP 端口65258来通信。第二个参数 "-debug" 告诉模拟器在运行main之前先停止并等待调试器。然后程序将暂停，所有的处理器停止。这有一个输出例子：

$ oct-sim  test.out -quiet -noperf -numcores=2 -uart1=65258 -debug
No -memsize argument provided, using default of 128 Megabytes
mem size is 128
Using simulator: pp
Loading test.out to boot bus address 0x1000000
Starting simulator....
Executing command: pp -ld=0x10000000:test.out -ld=0x0:0x8000000 -ld=0x1fe00000:0x1000 -modes=fastboot -ld=0x1fc00000:0x40000 -ld=0x1fc00000:/home/build/octsw/sdk/target/bin/u-boot.bin /home/build/octsw/sdk/target/bin/sim-magic-elf -ld=0x1ffffff0:/tmp/fileykZ0bG -ld=0x1ffffff8:/tmp/fileio660z -quiet -noperf -numcores=2 -uart1=65258
command line: pp -ld=0x10000000:test.out -ld=0x0:0x8000000 -ld=0x1fe00000:0x1000 -modes=fastboot -ld=0x1fc00000:0x40000 -ld=0x1fc00000:/home/build/octsw/sdk/target/bin/u-boot.bin /home/build/octsw/sdk/target/bin/sim-magic-elf -ld=0x1ffffff0:/tmp/fileykZ0bG -ld=0x1ffffff8:/tmp/fileio660z -quiet -noperf -numcores=2 -uart1=65258
Loading binary file test.out to address 0x10000000
Added 184 symbols from binary file: test.out
loading 240258 bytes
loaded 240258 bytes
Loading 134217728 bytes of zeroes to address 0x0
Loading 4096 bytes of zeroes to address 0x1fe00000
Loading 262144 bytes of zeroes to address 0x1fc00000
Loading binary file /home/build/octsw/sdk/target/bin/u-boot.bin to address 0x1fc00000
loading 105620 bytes
loaded 105620 bytes
Loading binary file /tmp/fileykZ0bG to address 0x1ffffff0
loading 8 bytes
loaded 8 bytes
Loading binary file /tmp/fileio660z to address 0x1ffffff8
loading 8 bytes
loaded 8 bytes
Loading executable file /home/build/octsw/sdk/target/bin/sim-magic-elf
Simulator magic DRAM at address 0xfeffe0000; not supported on hardware.
Loading 132 bytes to address FEFFE0000
Simulating with 2 pps
Found a sim_magic_trap thunk, setting address to 0x8000000feffe0000
Uart listening at localhost.localdomain, 127.0.0.1, port 65258 (0xfeea)


U-Boot 1.1.1 (Mar 14 2005 - 18:39:22)

DRAM:  128 MB
Using default environment


Bootloader: Booting Octeon Executive application at 0x10000000, core mask: 0x3, stack size: 0x100000, heap size: 0x300000
Bootloader: Done loading app on coremask: 0x3
waiting for a connection to uart 1 1
...

3) In the debugger terminal: Start mipsisa64-octeon-elf-gdb.

3)在调试器终端：开始mipsisa64-octeon-elf-gdb.

$ mipsisa64-octeon-elf-gdb
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=mipsisa64-octeon-elf".
(Core#0-gdb)

4) Select the file for debug and connect to the simulator.

4)选择调试的文件并连接到模拟器

(Core#0-gdb) file test.out
Reading symbols from /home/build/octsw/sdk/examples/debugger/test.out...done.
(Core#0-gdb) target octeon tcp::65258 -noperf -quiet -numcores=2
Remote target octeon connected to tcp::65258
(Core#0-gdb) load
Loading section .init, size 0x24 lma 0x10000018
Loading section .text, size 0xa370 lma 0x10000040
Loading section .fini, size 0x1c lma 0x1000a3b0
Loading section .rodata, size 0x628 lma 0x1000a3d0
Loading section .data, size 0xe70 lma 0x12000000
Loading section .eh_frame, size 0x4 lma 0x12000e70
Loading section .ctors, size 0x10 lma 0x12000e78
Loading section .dtors, size 0x10 lma 0x12000e88
Loading section .jcr, size 0x8 lma 0x12000e98
Loading section .sdata, size 0xb8 lma 0x12000ea0
Loading section .cvmx_shared, size 0x8 lma 0x14000000
Start address 0x10000148, load size 47412
Transfer rate: 379296 bits in <1 sec, 464 bytes/write.
(Core#0-gdb)

5) Debugging multicore works only on simple executive applications. The multicore debugging requires CIU interrupts that are defined in simple execute library. Just link the simple execute library to your applications, refer to debugger example for more details. To run the initialization code, set step-all to on. Also make sure the focused core is set to core 0.

5)多核的调试工作仅仅在SE应用程序上进行。多核调试需要CIU中断，CIU中断在SE库中被定义。将SE库链接到你的应用程序，更多细节请查看调试例子。要运行初始化代码，需将step-all打开。也要确保core 0被设置成focused core。

(Core#0-gdb) set step-all on

6) Place a break point on main and run.

6)在main上设一个断点并运行。

(Core#0-gdb) break main
Breakpoint 1 at 0x20000378: file test.c, line 67.
(Core#0-gdb) continue
Continuing.

Breakpoint 1, main () at test.c:62
62        int iNbr = 1;
(Core#0-gdb)

7) Disable step-all to debug the focused core.

7)关闭step-all以调试focursed core。

(Core#0-gdb) set step-all off

8) You can now issue normal gdb commands. Some useful ones are step, next, print, set variable, break, and continue.

8)现在你可以使用通常的gdb命令了。一些有用的命令是：step, next, print, set variable, break, 和continue.

15 Running the inter-core Debugger  运行inter-core 调试器

The debugger can be run under Linux on the Octeon Hardware and be able to debug other applications on other cores.

octeon 硬件上的调试器可以在linux下运行，且能调试其他核上的应用程序。

Before invoking the debugger, the program has to be running. See 19. Booting Simple Executive applications from Linux using bootoct for how to run a program while under Linux. Make sure the "debug" option is passed to the bootoct command.

开始调试器之前，要先运行程序。在linux下怎样去运行一个程序请看19. Booting Simple Executive applications from Linux using bootoct。确保"debug" 选项已传递给bootoct命令。

Now invoke the debugger using mipsisa64-octeon-elf-gdb command.

现在使用mipsisa64-octeon-elf-gdb命令打开调试器。

  # mipsisa64-octeon-elf-gdb -q test.out
@end_verbatim

This will provide you with a "(Core#0-gdb)" prompt just like the standard octeon debugger.
Connect to the inter-core target using:
@verbatim
  (Core#0-gdb) target octeon LINUX
    Remote target octeon connected to tcp::3001

This will provide you with a debugger that is able to do the standard octeon multicore debugger.

这将会给你提供一个可以去做标准octeon多核调试的调试器。

Note this connects to a oct-debug-agent program running on the Linux via tcp. The oct-debug-agent program can be added to the embedded_rootfs using "make menuconfig" under the linux/embedded_rootfs directory and the simple executive debugger for Linux as Simple exec gdb<

. If doing "target octeon LINUX" fails saying localhost does not exist, try moving aside /etc/resolv.conf.

注意这个到通过tcp运行在linux上的oct-debug-agent程序的连接。使用 linux/embedded_rootfs目录下的"make menuconfig" 和用于linux下的SE调试器如Simple exec gdb<，oct-debug-agent 程序可以被加到嵌入式根文件系统中。

如果 "target octeon LINUX"说明localhost不存在，可以试着移动到/etc/resolv.conf.