Add full support for data breakpoints

[puremourning]

RFC - Opening this to see if you're interested in the contribution. I'm working on implementing data breakpoints in vimspector, and as always it's much easier to hack codelldb than anything else, so I implemented the extra features from DAP spec. Only lightly tested at this point.

---

Currently, we only provode support for data breakpoints where the request is for a child of some container using variables_reference. However, the spec includes support for:

• an arbitrary expression, and
• an arbitrary address, and
• an optional size in bytes.

The later two are supported via a capability
"supportsDataBreakpointBytes". We add support for all of these options.

It's fairly trivial to evaluate an expression and do esentially what we do now for children (find the load address, check its size). But we can also accept a size, so long as it's valid watchpoint size. Similarly for addresses, if 'asAddress' is supplied we can just try to use it. It will probably fail if the address is actually invalid, but that's sort of the point.

[vadimcn]

Would be great to have that. These extra options were added after I implemented data breakpoints.

[puremourning]

Spent a bunch more time testing this and good news/bad news.

Good news: All the hackery that I added for calculating which watchpoints to actually add is completely unnecessary. LLDB is supposed to do that all by itself.

Bad news is that this clearly doesn't actually work in some versions on LLDB (at least on my platform, Mac arm64).

LLDB master works fine, but the bundled LLDB 19.1.0-custom seems to fail when watched sizes are > about 24 bytes.

Looks like this might have been added in llvm/llvm-project#79962

Either way, I'm thinking to remove all of the complexity from CodeLLDB and whenever it starts working in libLLDB, then we'll just start reaping the benefits, rather than implementing a half-baked version of the above PR here.

[puremourning]

Pushed the simplified version of the change. The second commit message covers the situation:

Current released versions of lldb have seeming partial support for
"large" watchpoints. That is they break a user requested watchpoint and
size into specific minimal set of working hardware watchpoints supported
by the target.

Full support for this is in progress in master and works well, allowing
to watch any address that's part of some larger structure. In any case,
CodeLLDB rejecting a watch due to its size is swimming against the tide
and by removing the size restriction we can take advantage of whatever
support LLDB adds in the future versions without code changes.

The drawback is that we get a slightly less precise error
"Setting one of the watchpoint resources failed" in the case where the
size is not currently supported.

Let me know what you think.

[puremourning]

Actually it's a bit more confusing. If I build lldb 19.1.0 branch from source it works fine for arbitrary sizes, just not with the bundled liblldb.dylib. Strange.

[puremourning]

Here's a demo in vscode.

You can see the slightly broken behaviour for the larger array (t.big is a large char array).

here's it with a custom build lldb 19.1.0:

Either way demos show:

• picking a variable to watch from he variables view
• entering an address and size

[vadimcn]

Looking... How does one enter an expression whose result to watch in VSCode?

[vadimcn]

Pulled this in

[vadimcn]

Hmm, looks like SBWatchpointOptions was added in lldb 18, so this change breaks compatibility with older liblldb's: #1221

[puremourning]

Ugh. I didn't consider backward compat with lldb. Assumed you only supported 'at least as new' as the one in codelldb.

I'll need to find some time to look into it and I'm chocca this weekend.

If it's urgent fix I guess revert and we can go again?

[vadimcn]

I think I'll change it back to WatchAddress and then fix this in LLDB itself.

[puremourning]

I have a patch and test for lldb. I'll submit it today.

[puremourning]

Here: llvm/llvm-project#124847