Post History
Does C have a mechanism which lets me mark a section of code such that breakpoints are somehow ignored or not allowed just in that section? Generally compilers are completely unaware of debugg...
Answer
#2: Post edited
- > Does C have a mechanism which lets me mark a section of code such that breakpoints are somehow ignored or not allowed just in that section?
- Generally compilers are completely unaware of debuggers. Code and debuggers are supposed to be completely trasparent to each one for obvious reason (you want to code to behave in the same way it always do while you are debugging).
- But but but
- (That's not a good practice)
- Technically it can be feasible programatically. Afaik all debuggers doesn't nothing more than writing and reading on system bus. Taking your specific platform as an example, you can write the same debug peripheral, as the debugger would, to disable all breakpoints before your critical section and then re-enable them at the end. (Provided they are hardware breakpoint, software one are another story)
- So, depending on your micro, before entering critical code, you could backup the value of FUNCTION field of the DWT_FUNCTIONn registers, disable all the breakpoint putting FUNCTION to zero, and then after the critical code, write back the original value.
It is horrible but it works.- In practice, most of the time you just want to comment out the row of code that can be problematic. If this is not possible what you need is tracing. So provided that you microcontroller supports it, go get a look about coresight functionalities.
- > Does C have a mechanism which lets me mark a section of code such that breakpoints are somehow ignored or not allowed just in that section?
- Generally compilers are completely unaware of debuggers. Code and debuggers are supposed to be completely trasparent to each one for obvious reason (you want to code to behave in the same way it always do while you are debugging).
- But but but
- (That's not a good practice)
- Technically it can be feasible programatically. Afaik all debuggers doesn't nothing more than writing and reading on system bus. Taking your specific platform as an example, you can write the same debug peripheral, as the debugger would, to disable all breakpoints before your critical section and then re-enable them at the end. (Provided they are hardware breakpoint, software one are another story)
- So, depending on your micro, before entering critical code, you could backup the value of FUNCTION field of the DWT_FUNCTIONn registers, disable all the breakpoint putting FUNCTION to zero, and then after the critical code, write back the original value.
- There's a small chance that the debugger program you breakpoint while you are in the critical section so you can still burn your led if you put breakpoints while the code in free-running.
- In practice, most of the time you just want to comment out the row of code that can be problematic. If this is not possible what you need is tracing. So provided that you microcontroller supports it, go get a look about coresight functionalities.
#1: Initial revision
> Does C have a mechanism which lets me mark a section of code such that breakpoints are somehow ignored or not allowed just in that section? Generally compilers are completely unaware of debuggers. Code and debuggers are supposed to be completely trasparent to each one for obvious reason (you want to code to behave in the same way it always do while you are debugging). But but but (That's not a good practice) Technically it can be feasible programatically. Afaik all debuggers doesn't nothing more than writing and reading on system bus. Taking your specific platform as an example, you can write the same debug peripheral, as the debugger would, to disable all breakpoints before your critical section and then re-enable them at the end. (Provided they are hardware breakpoint, software one are another story) So, depending on your micro, before entering critical code, you could backup the value of FUNCTION field of the DWT_FUNCTIONn registers, disable all the breakpoint putting FUNCTION to zero, and then after the critical code, write back the original value. It is horrible but it works. In practice, most of the time you just want to comment out the row of code that can be problematic. If this is not possible what you need is tracing. So provided that you microcontroller supports it, go get a look about coresight functionalities.