Cart New Account Login

HomeAbout usProductsSupportForumsBlogCustomer Service

search inside this forum
search inside all forums
Any way to set breakpoints without halting target in GDB?
Tom W. Dec 10, 2020 at 04:22 PM (16:22 hours)
Staff: Mika I.

  • Hi, we are using a Multilink Universal FX with GDB to debug a NXP KV46 micro, and we have discovered that the IDE (MCUExpresso) is causing the target to halt for 20 to 50 milliseconds whenever a breakpoint is set (that is *set*, as in I placed a breakpoint but have not actually hit it yet).

    The GDB console is showing that the IDE's GDB client is sending a SIGINT whenever I set any breakpoint, which makes sense from the command-line client perspective, because you have to interrupt the client in order to issue a breakpoint command.

    The only information I can find online about how to set breakpoints while the target is running is to use ctrl+c to send the SIGINT, which obviously makes sense when debugging another program on the same host, but for a remote server I was expecting there to be some way to tell it to set a breakpoint without interrupting the running program. Obviously this is a desired feature, since all IDEs allow you to set a breakpoint while the target is running.

    Is there some way to do this with GDB? If not, are there other tools which are able to do this?

    For some background on why I am asking about this:

    This 10-20 ms of delay is problematic for applications which use PWM output to control a motor, for example, and for larger motors this brief pause could lead to permanent damage. We have verified that this problem does not exist with TI's C2000 processor and debugging tools. From what I have read about the ARM coresight debug architecture I don't believe it needs to halt the processor to configure breakpoint comparator registers (but I am admittedly out of my depth in this area).

    These "exploratory breakpoints" have been a useful tool when trying to find the root cause of bugs where we do not know where to place the (limited) breakpoints at the start of a debug session. For example, after attaching to a micro we may set a few different breakpoints to determine what portion of code the micro is stuck in, or which path it is taking through some process. If we have to re-set the system every time to set a breakpoint we would not only lose our time, but for infrequent failure modes we would almost certainly lose the information we were looking for.

    Thanks in advance


  • Hi Tom,

    Thanks for reaching out.

    Unfortunately, GDB doesn't allow commands to be executed while the processor is running. So when you set a breakpoint, in the background, GDB halts the processor, then sets the breakpoint, then resumes the processor again, resulting in the delay that you are noticing.

    You are right that ARM processors don't require the processor to halt in order to set a breakpoint, but since GDB is generic, it probably uses this method in order to be safe for non-ARM processors. But this would mean that ARM-specific software like TI's could breakpoint without halting, as you mentioned.

    I'm very sorry that I don't have a workaround for you in MCUXpresso.


    • Hi Mika, thanks for the response.

      It does seem like GDB is intentionally designed to prevent this. Even in asynchronous mode it simply informs you that you have to halt the process to issue breakpoint commands.

      One way that might solve this issue is the "non-stop" mode of GDB, but that is not implemented in PEMicro's GDB server. In this mode it looks like you can at least get values of registers and variables while the process is running, so that gives me hope that it may also allow breakpoints to be set in a non-intrusive manner.

      Also, do you know if there is a way to use PEMicro debuggers to insert breakpoints outside of GDB? Like a lower-level interface that is not tied down by the GDB abstraction.

      For example, OpenOCD has its own lower-level commands for reading memory and setting breakpoints, and it is able to read memory contents while running. I haven't found any sources that say whether it can also set breakpoints when running, but I will try to test this out sometime soon.

      Here is an article about how VisualGDB is able to use OpenOCD to provide features that GDB can't provide on its own:

  • Hi Tom,

    Thank you for this suggestion. I have relayed it to my team, and we will work on utilizing the non-stop mode to try to remedy the breakpoint halting that you are experiencing.

    Unfortunately for now, we do not have a way to insert breakpoints without GDB. But I will let you know how our progress looks with the non-stop mode in GDB.

    Thanks again.


    • Hi Mika,

      Thanks, it would be interesting to get feedback on this from those who implement these things, since there may be some constraint I am not aware of.

      On Friday I was able to verify that I can use the "raw" OpenOCD interface (no GDB) to set a breakpoint without halting, as expected.

      It would take some work to make this actually useful, but it does prove that the constraint is artificial (at least for cortex-m micros).

      I am not certain that non-stop mode would fix this issue (that is a question for the experts), but at the very least it should be possible to modify the GDB server to allow a "non-halt breakpoint" feature in the same way that you add in non-GDB features for reading live data while the micro is running.

      Also, we ran a similar test using a Multilink Universal FX with a DSC micro in the Kinetis IDE (which does not appear to use GDB, but we are not sure), and it also suffers from the pause problem.


  • Hi Tom,

    We will definitely update you with what we find. Our GDB server supports ARM and non-ARM devices, so any changes we make will need to work for both.


Add comment

   Want to comment? Please login or create a new PEmicro account.

© 2021 P&E Microcomputer Systems Inc.
Website Terms of Use and Sales Agreement