Haneef Mohammed

So, it would be all or nothing. By default gdb does the right thing based on memory map. I have a feeling I will get tons of issues asking me...

> Well, on my target (Raspberry Pi Pico), I cannot place a SW breakpoint on code which is run from the flash And, rightfully, you shouldn't try to use a...

So all you are looking for a graceful rejection of a failed breakpoint? But the debugger is still functional? If the latter is untrue, I can do something about that.

GDB will barf regardless of if you exceeded the limit set by you `hardware-breakpoint-limit` or by the gdb-server because it ran out of HW slots. Either way, the command we...

> option to override breakpoint type would provide a handy workaround This is the part I am not getting. Workaround for what?. Workaround to a faulty gdb-server? Or how that...

``` Warning: Cannot insert hardware breakpoint 4:Remote failure reply: 0E. 0x100003ce in main () at C:\tools\pico-testing\hello-world\main.c:28 28 gpio_put(PIN_LED, false); ``` So what happens after this with Cortexx-Debug. I have run...

Ahhh, I see @recursivenomad You are saying it looks like an exception occurs which is like hitting a breakpoint and the debugger stops right there, requiring a manual continue? Is...

> to the best of my understanding is an issue where their target does not accept SW breakpoints, even in RAM (but somehow does handle HW breakpoints in RAM), and...

Lets keep the issue faced by @recursivenomad separate from @litui Completely different issues and from your perspectives, this feature will satisfy both. I don't see it that way. Issues should...

> PS: I believe @recursivenomad even brought up bad memory mapping as a potential reason for this earlier too. That can occur regardless of whether one is a "BMP user",...