Setting hardware (vs software) breakpoints?

I’m working on getting debugging of a small ARM Cortex M0 processor (Microchip SAMD21x) working. I’ve had some success, but while the MCU supports up to four hardware breakpoints, lldb doesn’t seem to set hardware breakpoints (via OpenOCD).

When I set a breakpoint by connecting to OpenOCD via telnet, everything works fine. A software breakpoint set via lldb is never triggered.

Is there a way to tell lldb to set a hardware breakpoint? Is there some change that needs to be made to the code?

EDIT: Issuing settings set target.require-hardware-breakpoint true causes subsequent breakpoints set to be hardware breakpoints, and the debugger stops. It’s not always reliable (seems to depend on the specific line chosen), but it works a bit better.

There’s a -H flag to “break set” to request a specific breakpoint be hardware if possible. There’s also a setting:

target.require-hardware-breakpoint

that will force breakpoints to only be hardware. Since stepping also uses breakpoints if you restrict lldb to the 4 or so hardware breakpoints available, you might see some more complex stepping operations fail. But if you only can set hardware breakpoints, you are in a bit of a world of pain anyway.

Jim

Is that documented somewhere (the -H option)? I can only get help from lldb for breakpoint, not for breakpoint set.

And yeah, the target executes out of flash. I assume software breakpoints replace an instruction to trap into the debugger?

| JetForMe
January 10 |

  • | - |

Is that documented somewhere (the -H option)? I can only get help from lldb for breakpoint, not for breakpoint set.

Should be part of the output of:

(lldb) help break set

Sets a breakpoint or set of breakpoints in the executable.

Does help break set not work for you?

And yeah, the target executes out of flash. I assume software breakpoints replace an instruction to trap into the debugger?

Yes, that’s how software breakpoints are done.

Jim

1 Like

Ah, yes. I was trying break set help and break help, following what I thought was LLDB’s (and other tools’) pattern of noun verb. That’s very helpful, thank you.

help is the noun here (it’s the primary command). If we were being pedantic about the noun verb thing we would have help lookup ... but there was nothing else help was going to do but lookup commands and print their help so the verb was elided in this case.

Jim

I get that now, but I’d argue it’s counter-intuitive. You’re thinking about the thing you’re trying to do first (e.g. something with breakpoints), and if help is “show help,” then break help makes more sense. There’s precedent for it in other commands as well. It’s also cleaner from an implementation point of view: each subcommand takes charge of its own help.

Because break help worked, but break set help didn’t, I figured break help was all the help there was.

In any case, I know better now.

I didn’t even know that was there. IMO that’s kind of awful. I must not have been paying attention when somebody put in that virtual help sub-command.

It is entirely undiscoverable since it never shows up as a subcommand in the “help”. And whoever did it did it wrongly since it only works one level deep in the command tree. It also doesn’t complete:

(lldb) break h

does nothing so it’s not a real part of the command. And unlike every other command word in the lldb command set, it doesn’t do shortest unique string matching, you have to type “help”.

And after all, you need to have a “help” command or there would be no way to figure out what commands and aliases are available. Given that, having do to:

(lldb) help

to see that there’s a breakpoint command, then:

(lldb) break help

to get the breakpoint help just seems weird.

Next time I have some free time, I’ll go yank that out.

Jim

2 Likes

When you set a breakpoint and don’t specify a hardware breakpoint, LLDB will try to set a software breakpoint with a “Z0” packet. In your case, running out of flash, OpenOCD’s gdbserver should try to set the software breakpoint, see that it failed, and return an error. Then LLDB will try to set a hardware breakpoint with a “Z1” packet.

Perhaps you should talk to whoever writes your OpenOCD gdbserver and have them verify that software breakpoints are actually set, by reading the address of the breakpoint to make sure that the software breakpoint instruction was written successfully.

1 Like