[SOLVED] GDB server - read data structures while target is running

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] GDB server - read data structures while target is running

    Hello,

    is ist possible to configure a setup for:
    a) Segger GDB Server connection via JLink to target (Cortex-M7)
    b) GNU ARM arm-none-eabi-gdb client connected to it
    b1) where program execution is not interrupted (in any way even for the shortest amount of time)
    b2) getting gdb client to perform "print my_data_structure" while target is running

    ?

    So far I only managed to get the following:
    - Connection to target via JLink
    - GDB connection out of Eclipse via "GDB SEGGER J-Link Debugging"; I could also connect the gdb client purely from command line (without any difference)
    - get it connected to the target
    - but I always do see an interruption / halt
    - (followed by a continue)
    - when connected to the target and it is running, I am not able to enter a command to the gdb client, since it seems to be "locked by the gdb server"
    - only if I halt the target, I can write commands via the gdb client

    Did I overlook some config options?

    If I want to read from / write to target memory without any sort of interruption / halt I have to connect to the running target with J-Link Commander (then use commands like mem32, w4) ... and therefore I lose the advantage of having GDB in combination with the ELF file (for "automatic symbol to address conversion" ... e.g. "(gdb) print my_data_structure")

  • Hi,


    there are multiple options:

    1)
    You can use the monitor commands in the GDB-Client to directly pass commands to the J-Link software. e.g. "monitor memU32 0x20000000" in order to read 4 Bytes from 0x20000000.
    The monitor commands are documented in UM8001 chapter "J-Link software and documentation package", section "J-Link GDB Server", subsection "Supported remote (monitor) commands".

    2)
    You can use an IDE or debugger which supports monitoring of variables during run time on Cortex-M target, e.g. SEGGER embedded Studio or Ozone - the J-Link Debugger.

    3)
    You can start the debug session as usual with J-Link GDB Server and Client, and then use the "Connect to running target" feature of J-Scope in order to track variables in RAM.

    when connected to the target and it is running, I am not able to enter a command to the gdb client, since it seems to be "locked by the gdb server"

    This sounds unusual. Which GDB Client do you use? Could you sent us a screenshot of this behavior?


    Best regards,
    Niklas
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • Hi,

    Thanks for the reply.

    when connected to the target and it is running, I am not able to enter a command to the gdb client, since it seems to be "locked by the gdb server"
    Seems to me like it has something to do with the combination of Eclipse + Eclipse GNU ARM + JLink Debug plugin + GNU ARM 5.4 arm-none-eabi-gdb.exe + JLinkGDBServerCL.exe. Not sure what causes the problem. I can enter the commands in the Eclipse console for arm-none-eabi-gdb.exe, but they do not execute during run, only when I halt the target in Eclipse.


    Just to make sure I ran the following lines directly from command-line completely skipping Eclipse:

    SEGGER: JLinkGDBServerCL.exe -Device ATSAME70N20 -if SWD -speed 4000 -noir -nohalt
    Output of JLinkGDBServerCL.exe:
    JLinkARM.dll V6.12j (DLL compiled Feb 15 2017 18:01:10)

    -----GDB Server start settings-----
    GDBInit file: none
    GDB Server Listening port: 2331
    SWO raw output listening port: 2332
    Terminal I/O port: 2333
    Accept remote connection: localhost only
    Generate logfile: off
    Verify download: off
    Init regs on start: off
    Silent mode: off
    Single run mode: off
    Target connection timeout: 0 ms
    ------J-Link related settings------
    J-Link Host interface: USB
    J-Link script: none
    J-Link settings file: none
    ------Target related settings------
    Target device: ATSAME70N20
    Target interface: SWD
    Target interface speed: 4000kHz
    Target endian: little

    Connecting to J-Link...
    J-Link is connected.
    Firmware: J-Link V9 compiled Dec 16 2016 15:34:10
    Hardware: V9.10
    S/N: XXXXXXXXXXXXXX
    Feature(s): GDB
    Checking target voltage...
    Target voltage: 3.28 V
    Listening on TCP/IP port 2331

    GNU ARM arm-none-eabi-gdb.exe: file myProg.elf
    GNU ARM arm-none-eabi-gdb.exe: target extended-remote localhost:2331

    Output of JLinkGDBServerCL.exe:
    Connecting to target...Connected to target
    Waiting for GDB connection...Connected to 127.0.0.1
    Reading all registers
    ...Target halted (PC = 0x20400474)

    In command window of GNU ARM arm-none-eabi-gdb.exe:
    (gdb) monitor go


    from there on the system executed the code, and running the "print myVar" command worked as expected / desired while the mcu was in run.
    Question left is: why is the target halted when the gdb client connects to the server? are there any options/commands to prevent this?

  • From the SEGGER GDB Server (v6.12j) log you can see, that as soon as the GDB Client (launchpad gnu arm 5.4 2016q2 arm-none-eabi-gdb.exe) connects the function JLINK_Halt() gets called.

    ...
    03-00000000-00-00000560-001D: Waiting for GDB connection...
    02-00000000-00-00002416-0049: T25CC 002:466 JLINK_GetHWStatus(...) returns 0x00 (0002ms, 0521ms total)
    ...
    02-00000000-00-01216453-004A: T25CC 1216:502 JLINK_GetHWStatus(...) returns 0x00 (0003ms, 2545ms total)
    03-00000000-00-01217435-0016: Connected to 127.0.0.1
    03-00000000-00-01217649-0015: Reading all registers
    02-00000000-00-01217653-0045: T1964 1217:701 JLINK_IsHalted() returns FALSE (0004ms, 2549ms total)
    02-00000000-00-01217685-0040: T1964 1217:705 JLINK_Halt() returns 0x00 (0032ms, 2577ms total)
    02-00000000-00-01217685-0044: T1964 1217:737 JLINK_IsHalted() returns TRUE (0000ms, 2577ms total)
    02-00000000-00-01217685-0051: T1964 1217:737 JLINK_ReadReg(R15 (PC)) returns 0x20400402 (0000ms, 2577ms total)
    03-00000000-00-01217694-0022: ...Target halted (PC = 0x20400402)
    02-00000000-00-01217694-004B: T1964 1217:746 JLINK_ReadReg(R0) returns 0x2045FEC0 (0000ms, 2577ms total)
    02-00000000-00-01217694-004B: T1964 1217:746 JLINK_ReadReg(R1) returns 0x2045FEBE (0000ms, 2577ms total)

    What is the reason for this behaviour?
    Is there any way to prevent / supress this function call? In my case this call messes up the timings with other chips on my board, which in the end leads to a non-observable state of the system.

  • Hi,
    What is the reason for this behaviour?

    At least older versions of GDB required the target to be in a known state on connect,
    which is: The target is halted and the register values are known.
    Therefore GDB Server halts the target and reads the registers.

    What you want to do is "attach" to the application running on your target and evaluate its current state, correct?

    To not halt the target and to not initialize the registers, there are the command line options you already used manually: -noir -nohalt

    After GDB is connected to GDB Server, the GDB Server will not do anything with the target,
    so halt or any other commands are issued by GDB.

    Please note, that when GDB connects to a running application, or any time when the application is running, you cannot issue any other command prior to halting the target.

    To read variable values while the target is running, there are different options:
    - Open a second connection to GDB Server and use the GDB Protocol commands to read memory
    - Use another debugger which is capable of reading variables while the target is running, for example Ozone, which is available free of charge for use with J-Link PLUS
    - Use J-Scope, which can read and display variable values with high speed while the target is running.

    Please note, that when you use the monitor commands, the GDB client does not update its internal state, so with monitor go it does not "know" that the target continued.

    Best regards
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • Concerning the GDB client: I used version 7.12.0 which should be a farily new one.

    Today I set up the connection via OpenOCD and it worked right away without ever halting the target.
    Meaning:
    a) In order to get OpenOCD to find the SEGGER J-Link I switched the USB driver to "Libusb - WinUSB".
    b) Connected with OpenOCD and the same SEGGER J-Link adapter to my target (ATSAME70)
    c) OpenOCD created the GDB server
    d) connected the same GDB client (version 7.12.0) to the OpenOCD GDB server
    e) GDB successfully connected without halting the target
    f) GDB command "print myVar" worked as expected

    Therefore I am not sure as to how this relates to your post concerning "After GDB is connected to GDB Server, the GDB Server will not do anything with the target".

  • Therefore I am not sure as to how this relates to your post concerning "After GDB is connected to GDB Server, the GDB Server will not do anything with the target".

    This means, the J-Link GDB Server sets up the connection to J-Link and target, and waits for the GDB connection.
    When GDB Server is started with -noir -nohalt, the target will still be running.

    When GDB connects to GDB Server, the target is still running, but the first thing GDB tries to do, is to read all CPU registers.
    To do this, GDB Server needs to halt the target.
    This is what you see in the GDB Server Log
    03-00000000-00-01217649-0015: Reading all registers
    ...
    03-00000000-00-01217694-0022: ...Target halted (PC = 0x20400402)
    ...

    Not sure why GDB needs to read the CPU registers, or how to prevent this.
    It looks like with OpenOCD either the registers are not read or OpenOCD returns invalid registers.

    e) GDB successfully connected without halting the target
    f) GDB command "print myVar" worked as expected

    With OpenOCD you can issue commands while the target is running?
    The default behavior of GDB is, that when the target application is running, after attach or continue command, it does not take any other command until you hit Ctrl-C or a breakpoint is hit.

    Regards
    Johannes
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • In OpenOCD console:
    GNU ARM Eclipse 64-bits Open On-Chip Debugger 0.10.0-00113-g0f83948 (2017-01-24-
    18:48)
    Licensed under GNU GPL v2
    For bug reports, read
    openocd.org/doc/doxygen/bugs.html
    atsame70n20
    Warn : Interface already configured, ignoring
    cortex_m reset_config sysresetreq
    adapter speed: 1000 kHz
    cortex_m reset_config sysresetreq
    Info : flash bank command
    srst_only separate srst_gates_jtag srst_open_drain connect_deassert_srst
    Info : J-Link V9 compiled Dec 16 2016 15:34:10
    Info : Hardware version: 9.10
    Info : VTarget = 3.282 V
    Info : clock speed 1000 kHz
    Info : SWD DPIDR 0x0bd11477
    Warn : Silicon bug: single stepping will enter pending exception handler!
    Info : atsame70n20.cpu: hardware has 8 breakpoints, 4 watchpoints
    Info : accepting 'gdb' connection on tcp/3333
    Info : device id = 0xa1020c00
    undefined debug reason 7 - target needs reset


    Looks like OpenOCD is not reading the registers.
    in GDB client console

    (gdb) target remote :3333
    Remote debugging using :3333
    0x00000000 in ?? ()
    (gdb) print gpTC1->TC_CV
    $1 = 33348
    (gdb) print gpTC1->TC_CV
    $2 = 51339

  • (gdb) target remote :3333
    Remote debugging using :3333
    0x00000000 in ?? ()

    The last line should tell that the target is halted (at 0 in this case, which is in an unknown function)
    But since your variable gpTC1->TC_CV changes, it seems that your target is still running. Correct?

    This shows that OpenOCD does not behave "correct" but seems to fake the current target status and probably the register read, too.

    Since J-Link GDB Server is used by various IDEs which rely on a correct target state we cannot fake this and will halt the target when GDB wants us to do this.

    So if you really require this behaviour, you will have to use OpenOCD or switch to a non-GDB debugger like Ozone.

    Best regards
    Johannes
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.