[libcxx-commits] [libcxx] WIP - [libc++][debugging] P2546R5: Debugging support & P2810R4: `is_debugger_present` `is_replaceable` (PR #81447)

[Jonathan Wakely via libcxx-commits]

jwakely wrote:

See https://discourse.llvm.org/t/runtime-support-for-std-is-debugger-present/79338?u=jwakely for the approach we're considering for libstdc++ and GDB, which is similar to @vogelsgesang's suggestion.

I completely agree that a better user experience would be for the debugger to recognize `std::breakpoint()` and `std::breakpoint_if_debugging()` and break in the user code where those functions are called (rather than inside those functions in std::lib code). And if the debugger does that, it should then not step into the function, but skip over it (because it already put a breakpoint there, so we don't need the `__builtin_debugtrap()`, `__builtin_trap()` etc. that the function body would do). GDB support for that is being discussed.

I also agree that an internal bool flag in the library is valuable. A public API like `__cxa_attach_debugger(bool)` would be useful for debuggers to set/clear the library's internal `bool` variable that says a debugger is present. `std::is_debugger_present()` would then check that bool flag. If the API is common to libc++ and libstdc++ then debuggers don't need to know 2+ different protocols for announcing when they're attached.

A suggestion for libstdc++ was that the "attach_debugger" API should return the address of `std::breakpoint`, as this might simplify things for the debugger if it wants to automatically insert a breakpoint on calls to that function. Otherwise the debugger has to be prepared to look up `std::breakpoint()`, or `std::__v1::breakpoint()`, or `std::__8::breakpoint()`, or `std::__other_inline_namespace::breakpoint()`. But if we want the debugger to treat `std::breakpoint_if_debugging()` the same way, then returning just the address of `std::breakpoint` is less useful.

https://github.com/llvm/llvm-project/pull/81447