[SOLVED] Unable to continue past bkpt instruction

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

  • [SOLVED] Unable to continue past bkpt instruction

    I have encountered a problem when debugging programs that issue a bkpt instruction using a J-Trace Cortex-M. I had originally posted the bug to GNU Tools for ARM Embedded Processors (the toolchain in question), however I was informed this could be an issue in the GDB server implementation provided by SEGGER:

    bugs.launchpad.net/gcc-arm-embedded/+bug/1383840

    If debugging a function that issues a bkpt instruction, arm-none-eabi-gdb correctly traps and prompts the user, however execution will not continue. Stepping past the instruction and then continuing works as expected:

    Source Code

    1. .global swbreak
    2. swbreak:
    3. bkpt #0
    4. mov pc, lr


    Source Code

    1. GNU gdb (GNU Tools for ARM Embedded Processors) 7.6.0.20140731-cvs
    2. Copyright (C) 2013 Free Software Foundation, Inc.
    3. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
    4. This is free software: you are free to change and redistribute it.
    5. There is NO WARRANTY, to the extent permitted by law. Type "show copying"
    6. and "show warranty" for details.
    7. This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".
    8. For bug reporting instructions, please see:
    9. <http://www.gnu.org/software/gdb/bugs/>...Program received signal SIGTRAP, Trace/breakpoint trap.
    10. swbreak () at ...
    11. 14 bkpt #0
    12. (gdb) c
    13. Continuing.Program received signal SIGTRAP, Trace/breakpoint trap.
    14. swbreak () at ...
    15. 14 bkpt #0
    16. (gdb) c
    17. Continuing.(ad infinitum)Program received signal SIGTRAP, Trace/breakpoint trap.
    18. swbreak () at ...
    19. 14 bkpt #0
    20. (gdb) s
    21. 15 mov pc, lr
    22. (gdb) c
    23. Continuing.(execution continues normally)
    Display All

    The post was edited 2 times, last by sstallion ().

  • Hi,

    Thanks for your post.
    J-Link GDBServer will only skip breakpoints on continue (Go) that are set via GDB + GDBServer.
    Other breakpoint instructions that might be in the code, must be skipped manually (Which should not be a big problem...).

    We may implement a monitor command, to enable a "skip SW BP in application code" but I cannot give you any promise or timeframe yet, as this is not a common case.
    Why do you see any need for a "swbreak" function which includes nothing than a breakpoint instruction and jump back to the caller?
    J-Link supports software breakpoints as well and will use them where appropriate.


    Best regards
    Alex
    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 Alex,
    Why do you see any need for a "swbreak" function which includes nothing than a breakpoint instruction and jump back to the caller?
    For portability. The RTOS I am using can target more than just Cortex-M cores, so hiding a software break behind a function call is very useful. The break gets embedded in critical areas that contain context (i.e. during a kernel panic). It makes GDB significantly easier to script since I don't have to worry about defining breakpoints for every possible failure.


    It's a little surprising that this doesn't work the same as breakpoints defined on the GDB command line - other GDB servers (notably OpenOCD) handle this without a problem. Manually skipping the breakpoint is a bit of a headache, especially for junior engineers. What is the utility in not skipping over the instruction once the debugger has trapped? Is there really a need to add a monitor command; this seems like a reasonable default?


    Cheers,

    Steve

    The post was edited 3 times, last by sstallion ().

  • Hi,

    main problem here is that we have to add instruction analysis for all architectures that we support,
    so we can identify if the current instruction is a breakpoint etc.
    Of course, in theory it can be added but we need to allocate resources for this "feature" (We had never a related request for GDB Server before...)
    and our resources are quite booked.

    Is there really a need to add a monitor command; this seems like a reasonable default?

    Where is the problem having a monitor command?
    Don't tell me that it would be a problem for you, to add it to your gdbinit...

    Regarding the default: I am not really happy with changing it, as this would result in different and for most users unexpected behavior in contrast to the current one.

    I will see what I can do, but I cannot promise anything or give any timeframe at this point.
    Will be part of the next meeting regarding feature requests for GDB Server.


    - Alex
    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,

    I discussed this internally and we decided to implement this in the not too distant future.
    After investigating the code and checking some cases, we decided to change the default behavior, so breakpoint instructions will just be overstepped by J-Link GDB Server.
    I will post it here, when the feature has been implemented but it may be a bit delayed, due to the current workload.
    So you may want to subscribe to the J-Link software update notification list: segger.com/notification/subscribe.php?prodid=7


    Best regards
    Alex
    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,

    I am not able to make this code working:

    C Source Code

    1. void __attribute__((noreturn)) __assert_func(const char *file, int line, const char *func, const char *failedexpr) {
    2. asm volatile("bkpt");
    3. abort();
    4. }



    Are the software breakpoints now supported ? I use a Segger J-Link Lite probe.
    Thanks for the information. Any help is welcome.

  • pruesch wrote:

    I'm also using a breakpoint instruction.

    but it requires a notation like this:
    bkpt #1
    I use the following code with several use of the `bkpt` instruction:

    C Source Code

    1. static inline void break_here(void) {
    2. __asm volatile("bkpt #1");
    3. __asm volatile("bkpt");
    4. __asm volatile( "bkpt #0x01;" "mov pc, lr;" );
    5. abort();}
    [/quote]Unfortunately, no alternative works. The processor does not halt when I can this function. I get the following output:

    Source Code

    1. Read 4 bytes @ address 0x00022C62 (Data = 0xBE00BE01)
    2. Starting target CPU......
    3. Breakpoint reached @ address 0x00022C62
    4. Reading all registers
    5. Read 4 bytes @ address 0x00022C62 (Data = 0xBE00BE01)
    6. Starting target CPU......
    7. Breakpoint reached @ address 0x00022C62
    8. ....


    I use a Segger J-Link lite probe and an nRF51822 processor, Eclipse as IDE with the latest version of the GNU ARM Eclipse J-Link plugin. My segger tools are:

    Source Code

    1. SEGGER J-Link GDB Server V5.12e Command Line Version
    2. JLinkARM.dll V5.12e (DLL compiled Apr 29 2016 15:03:58)



    Any help is welcome.

    The post was edited 1 time, last by metch ().

  • Hi,

    what does the compiled (disassembled code) like like?
    What happens if you place a Breakpoint on the end of the function using J-Link?


    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.

  • now I have the same problem.

    using the launchpad gcc arm none eabi toolchain. just upgraded and facing this problem.

    for me, it seems like the gdb 7.10 won't stop on a bkpt instruction. It somehow leads to an endless loop of halt and run at the gdb server side and renders it unresponsive.
    choosing a different gdb version seems to fix the problem.

    The post was edited 2 times, last by pruesch ().

  • Hi,

    There is an issue with the current version of GDB Server (V5.12g) and the latest GDB (V7.10)
    with software breakpoints, resulting in the endless halt/go loop.

    This will be fixed in the upcoming version, planned for this week.

    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.