Conditional memory address breakpoints (original) (raw)

Is there a way to set conditional breakpoints for memory addresses?

I.e. if I wanted to break when the program reaches any address higher than 0xffff800080000000?

It would require a hardware level feature of the CPU to do that, a form of a hardware breakpoint. It would be specific to the architecture (AArch64, x86-64, etc), and require support with the stub (lldb-server, debugserver) to set it. lldb would need a way to express that style of hardware breakpoint and send it to the stub to set - none of this exists today.

Offhand I don’t know of a processor that has a hardware breakpoint feature like that, but it may just be my own limited knowledge. Most processors have a small number (e.g. 4) hardware breakpoints so they’re not used by lldb most of the time, it’s too small of a number to be useful in general.

@jasonmolenda RISC-V triggers (usable for HWBPs) can match a triggering address greater than or equal to, or less than the provided value. That would work for @fastened 's use case.

ah cool, I didn’t know about that capability. The only time I’ve done anything fancy with a hardware breakpoint is on armv7 cores which have no instruction step capability, but they do have a hardware breakpoint that can express “when $pc is not equal to ADDRESS”, and set that to the current address and the processors stops after the current instruction has completed. But these kinds of things vary tons from processor family to processor family - AArch64/32 have instruction step and iirc do not have a hardware breakpoint feature like this.

I haven’t had to look into them since MIPS days but I will at some point for the new “FEAT_BWE” feature in AArch64 v9.3-a. Unfortunately even that won’t work for this case anyway:

“MASK, bits [28:24]
When FEAT_BWE is implemented:
Address Mask. Only address ranges up to 2GB can be watched using a single mask.”

(and you’d have to wait for a long time to see that in hardware, though I think it might be in Arm’s Foundation Model)

I don’t see any greater than option like Ted mentioned for RISC-V.

You can add a script to a breakpoint and transparently continue if it’s not what you want, but that’s going to take forever in this case.

Perhaps you can find something other than address range that is common to the code you want to stop in?

Other ideas I have not tried personally:

• Run it in a simulator and hack in a check for the PC being in that range.
• From lldb, call expressions to unmap all memory above that range (look at memory region --all), then wait for the application to crash and debug it from there.
• If that range does not contain real code (the program is jumping into that range because of a bug), map memory into it and fill it with the software break instruction for that architecture. LLDB will be a bit confused why it stopped, but it will stop (you won’t be able to continue, since LLDB doesn’t know about breakpoints it did not insert).