GDB support for user level application debugging

[feplo...@gmail.com]

Hi

Does anyone know how to debug application code using GDB? I can't find related information on either Tock or libtock-rs repositories. How does everyone debug application code?

Thanks for your help

Yu-Chieh

[Alistair Francis]

On Wed, Sep 9, 2020 at 10:22 AM feplo...@gmail.com
<feplo...@gmail.com> wrote:
>
> Hi
>
> Does anyone know how to debug application code using GDB? I can't find related information on either Tock or libtock-rs repositories. How does everyone debug application code?

There is nothing Tock specific about debugging with GDB. You can just
use GDB for your board/SoC the same way you would with any other
software running on the board. Generally that means using some
combination of JTAG and/or OpenOCD.

Alistair

>
> Thanks for your help
> Yu-Chieh
>

> --
> You received this message because you are subscribed to the Google Groups "Tock Embedded OS Development Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to tock-dev+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/tock-dev/51808dea-6114-4dc5-86fe-d6cdc6976e13n%40googlegroups.com.

[feplo...@gmail.com]

Hi Alistair

For kernel debug its setup is easier to understand since dev board is running kernel image directly and GDB server is running through OpenOCD or JLink is my case, but for application program it is running on top of kernel. Even though application program is also executed by dev board, I am not sure how gdb map application program's elf file on top of Tock kernel.

I've tried to run GDB server following instruction in Tock repo with following command: 

JLinkGDBServer -device nrf52 -speed 1200 -if swd -AutoConnect 1 -port 2331

Then connect GDB client with following setup command

target remote localhost:2331
monitor speed 30
file /home/leeyuc/libtock-rs/target/thumbv7em-none-eabi/tab/nrf52/blink/cortex-m4.elf
monitor reset

monitor speed auto
set remote memory-write-packet-size 1024
set remote memory-write-packet-size fixed

break main

As you can see above, I load with blink elf file instead of kernel elf file because I want to stop at blink's main function. However, gdb never stop at that point. Do you see any issue with my setup?

Thanks for your help

Yu-Chieh

[Alistair Francis]

On Thu, Sep 10, 2020 at 8:19 AM feplo...@gmail.com
<feplo...@gmail.com> wrote:
>
> Hi Alistair
>
> For kernel debug its setup is easier to understand since dev board is running kernel image directly and GDB server is running through OpenOCD or JLink is my case, but for application program it is running on top of kernel. Even though application program is also executed by dev board, I am not sure how gdb map application program's elf file on top of Tock kernel.
>
> I've tried to run GDB server following instruction in Tock repo with following command:
>
> JLinkGDBServer -device nrf52 -speed 1200 -if swd -AutoConnect 1 -port 2331
>
> Then connect GDB client with following setup command
>
> target remote localhost:2331
> monitor speed 30
> file /home/leeyuc/libtock-rs/target/thumbv7em-none-eabi/tab/nrf52/blink/cortex-m4.elf
> monitor reset
> monitor speed auto
> set remote memory-write-packet-size 1024
> set remote memory-write-packet-size fixed
> break main
>
> As you can see above, I load with blink elf file instead of kernel elf file because I want to stop at blink's main function. However, gdb never stop at that point. Do you see any issue with my setup?

Overall it looks correct.

I'm guessing that as the ARM applications are relocated at runtime
that the app is in a different location then where the elf is compiled
for. This then means that GDB doesn't match the addresses correctly.

I think add-symbol-files can take an address argument, you probably
want to use that and use the address of where the app is loaded. You
can edit kernel/src/config.rs to enable debug prints to see it.

Alistair

>
> Thanks for your help
> Yu-Chieh
> On Wednesday, September 9, 2020 at 12:28:51 PM UTC-5 alist...@gmail.com wrote:
>>
>> On Wed, Sep 9, 2020 at 10:22 AM feplo...@gmail.com
>> <feplo...@gmail.com> wrote:
>> >
>> > Hi
>> >
>> > Does anyone know how to debug application code using GDB? I can't find related information on either Tock or libtock-rs repositories. How does everyone debug application code?
>>
>> There is nothing Tock specific about debugging with GDB. You can just
>> use GDB for your board/SoC the same way you would with any other
>> software running on the board. Generally that means using some
>> combination of JTAG and/or OpenOCD.
>>
>> Alistair
>>
>> >
>> > Thanks for your help
>> > Yu-Chieh
>> >
>> > --
>> > You received this message because you are subscribed to the Google Groups "Tock Embedded OS Development Discussion" group.
>> > To unsubscribe from this group and stop receiving emails from it, send an email to tock-dev+u...@googlegroups.com.
>> > To view this discussion on the web visit https://groups.google.com/d/msgid/tock-dev/51808dea-6114-4dc5-86fe-d6cdc6976e13n%40googlegroups.com.
>
> --
> You received this message because you are subscribed to the Google Groups "Tock Embedded OS Development Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to tock-dev+u...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/tock-dev/5e103380-8f00-4290-ba1d-483fc2224b28n%40googlegroups.com.

[Philip Levis]

Amit knows this best, but this is what I recall:

Because CortexM processes are relocated, you do need to do some special tricks. You can either statically link the application into the kernel image, or you can recompile the application image with the offsets it’s been placed at in the kernel. When you get a kernel dump from an application panic you get these offset constants. One approach would be to see how the panic handler gets these values, then print them out at boot, so you can recompile your application image with them and use it as the debugging symbol reference.

Phil

To view this discussion on the web visit https://groups.google.com/d/msgid/tock-dev/5e103380-8f00-4290-ba1d-483fc2224b28n%40googlegroups.com.

———————
Philip Levis (he/him)
Associate Professor, Computer Science and Electrical Engineering

Faculty Director, lab64 Maker Space
Stanford University
http://csl.stanford.edu/~pal

[Pat Pannuto]

There is a `make debug` target in the build system that will generate elf files with symbols at the right offsets:

[-bash] Thu 10 Sep 09:41 [[master] ~/code/helena-project/libtock-c/examples/blink]
$ make debug
  LD        build/cortex-m0/cortex-m0.elf
ERROR: Required variables RAM_START and FLASH_INIT are not set.
       These are needed to compute the offset your program was loaded at.
       See the kernel panic message for these values.

You should be able to enable the config::CONFIG.debug_load_processes option to see where the process was placed in memory to get these values. (Aside: maybe the process console should list these if it doesn't already...)

HTH,

-Pat

To view this discussion on the web visit https://groups.google.com/d/msgid/tock-dev/CE08FC51-60EB-43F4-9AED-BA8546E5709E%40cs.stanford.edu.

[feplo...@gmail.com]

Thanks for the information but I am still not hitting breakpoints for application program for some reasons. Below is what I have done.

1.I used a modified blink program to cause crash in order to trigger panic handler. And I got following dump in UART:

Initialization complete. Entering main loop

panicked at 'Process blink had a fault', /home/leeyuc/.rustup/toolchains/nightly                                      -2020-06-03-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/macros/mod                                      .rs:16:9
        Kernel version release-1.5-1096-gad9387a57

---| Debug buffer not empty. Flushing. May repeat some of last message(s):
NRF52 HW INFO: Variant: Unspecified, Part: N52832, Package: QF, Ram: K64, Flash:                                       K512
Loading processes from flash=0x00030000-0x0007FFFF into sram=0x20002000-0x2000FF                                      FF
Loaded process[0] from flash=0x00030000-0x00030FFF into sram=0x20002000-0x20003F                                      FF = "blink"

---| No debug queue found. You can set it with the DebugQueue component.

---| Fault Status |---
No Coprocessor Usage Fault:         true
Forced Hard Fault:                  true
Fault Status Register (CFSR):       0x00080000
Hard Fault Status Register (HFSR):  0x40000000

---| App Status |---
App: blink   -   [Fault]
 Events Queued: 0   Syscall Count: 0   Dropped Callback Count: 0
                                                                 Restart Count:                                       0
  Last Syscall: None

 ╔═══════════╤══════════════════════════════════════════╗
 ║  Address  │ Region Name    Used | Allocated (bytes)  ║
 ╚0x20004000═╪══════════════════════════════════════════╝
             │ ▼ Grant        1032 |   1032
  0x20003BF8 ┼───────────────────────────────────────────
             │ Unused
  0x20002C00 ┼───────────────────────────────────────────
             │ ▲ Heap            ? |      ?               S
  ?????????? ┼─────────────────────────────────────────── R
             │ Data              ? |      ?               A
  ?????????? ┼─────────────────────────────────────────── M
             │ ▼ Stack           ? |      ?
  0x20002BE0 ┼───────────────────────────────────────────
             │ Unused
  0x20002000 ┴───────────────────────────────────────────
             .....
  0x00031000 ┬─────────────────────────────────────────── F
             │ App Flash      4032                        L
  0x00030040 ┼─────────────────────────────────────────── A
             │ Protected        64                        S
  0x00030000 ┴─────────────────────────────────────────── H

  R0 : 0x00000000    R6 : 0x00000000
  R1 : 0x00000000    R7 : 0x00016000
  R2 : 0x00000000    R8 : 0x00000000
  R3 : 0x20002C00    R10: 0x00000000
  R4 : 0x20002D34    R11: 0x00000000
  R5 : 0x00000000    R12: 0x3B6121AE
  R9 : 0x00000000 (Static Base Register)
  SP : 0x20002BE0 (Process Stack Pointer)
  LR : 0x00000001
  PC : 0x00030084
 YPC : 0x00000000

 APSR: N 0 Z 0 C 1 V 0 Q 0
       GE 0 0 0 0
 EPSR: ICI.IT 0x00
       ThumbBit true

 Cortex-M MPU
  Region 0: [0x20002000:0x20004000], length: 8192 bytes; ReadWrite (0x3)
    Sub-region 0: [0x20002000:0x20002400], Enabled
    Sub-region 1: [0x20002400:0x20002800], Enabled
    Sub-region 2: [0x20002800:0x20002C00], Enabled
    Sub-region 3: [0x20002C00:0x20003000], Enabled
    Sub-region 4: [0x20003000:0x20003400], Disabled
    Sub-region 5: [0x20003400:0x20003800], Disabled
    Sub-region 6: [0x20003800:0x20003C00], Disabled
    Sub-region 7: [0x20003C00:0x20004000], Disabled
  Region 1: [0x00030000:0x00031000], length: 4096 bytes; ReadOnly (0x6)
    Sub-region 0: [0x00030000:0x00030200], Enabled
    Sub-region 1: [0x00030200:0x00030400], Enabled
    Sub-region 2: [0x00030400:0x00030600], Enabled
    Sub-region 3: [0x00030600:0x00030800], Enabled
    Sub-region 4: [0x00030800:0x00030A00], Enabled
    Sub-region 5: [0x00030A00:0x00030C00], Enabled
    Sub-region 6: [0x00030C00:0x00030E00], Enabled
    Sub-region 7: [0x00030E00:0x00031000], Enabled
  Region 2: Unused
  Region 3: Unused
  Region 4: Unused
  Region 5: Unused
  Region 6: Unused
  Region 7: Unused

To debug, run `make debug RAM_START=0x20002000 FLASH_INIT=0x3006c`
in the app's folder and open the .lst file.

2.From the information at the end of the dump, I see it also print out

RAM_START=0x20002000 FLASH_INIT=0x3006c

So I use that for my layout_nrf52.ld

MEMORY {

/* The application region is 64 bytes (0x40) */

FLASH (rx) : ORIGIN = 0x0003006c, LENGTH = 0x0005FFC0

SRAM (rwx) : ORIGIN = 0x20002000, LENGTH = 62K

}

3.Connect to GDB as specified in tock repo and it still not hitting it.

(gdb) monitor reset
Resetting target
(gdb) b main
Note: breakpoint 1 also set at pc 0x301e4.
Breakpoint 2 at 0x301e4
(gdb) c

Continuing.

I can see that the address of gdb breakpoints is based on FLASH_INIT instead of SRAM address and I wonder if that is the reason?

Thanks for your help

Yu-Chieh