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

[René Ferdinand Rivera Morell via libcxx-commits]

grafikrobot wrote:

> @vogelsgesang
> 
> Thank you for starting a discussion. You made some interesting and useful points/info.
> 
> > and would then do the actual work inside lldb / gdb / _your favorite debugger_.
> 
> If I understand you correctly and to my knowledge about what Standard library function should be this is not how it should be implemented. The purpose of a Standard library features is not to provide the "best performing" solution in a specific context but one that is generic and usable in generic context. I don't believe that any feature of the library should depend on a third-party tool to function. P2546R5 references several reference implementations and I think that's what it is proposing. Such implementation will work on any support platform using system provided functionality only.

While it's true that the intent is not to provide performance-over-quality in the debugging support functionality.. Having a better performing debugging support would be a nice QoI. The implementations I referred to in the paper are what's possible from just a library solution. I *was* hoping something better could be accomplished with the help of debuggers themselves as @vogelsgesang proposed. But the wg21 discussions always acknowledge that it's all a best effort deal. For example, there was always an expectation in the wg21 discussions that `breatpoint()` would amount to the the single debug interrupt instruction. So there was some thinking of that being optimized. I.e. that it would be okay if users never saw the `breakpoint` call itself.

> I think your solution is more like a debugger specific extension and not fit for a Standard library and it maybe good if the debuggers support it (I don't know if they do).

I think it's fine for such extensions to be possible.

> > In lldb / gdb, this would require some special handling of those debugging functions. But for a good user experience, dedicated lldb support might be necessary, anyway, as previously noted in:
> > > debugger support: when the debugger breaks in breakpoint() it breaks inside the implementaiton, which isn't an optimal user experience. Perhaps LLDB (the debugger) can be thought to break on breakpoint() call site, similar to the /JMC option in MSVC but this is unrelated work to this patch.
> 
> This idea is just to enhance the user experience and is not required for the `<debugging>` functions to work.

Yes, true. But "enhance" has varying levels of meaning. :-)

> This is how I understand it. Hopefully it makes sense. I may be completely wrong but the purpose of the PR is also to collect opinions and suggestions..

I think the base library solution should be formulated such that better integrations are possible and hopefully easily. @vogelsgesang 's suggestion shows some possibility to improve this one by having an internal hook that lldb/gdb can set to get a more definitive and quicker answer for `is_debugger_present`. To marry the two solutions perhaps this approach could work:

```
namespace std {

bool __is_debugger_present_flag = false;
bool* __is_debugger_present_hook = nullptr;
bool is_debugger_present() noexcept
{
  if (__is_debugg_pressent_hook) return *__is_debugger_present_hook;
  else __is_debugger_present();
}
```

That way a smart debugger can set the `__is_debugger_present_flag` and set `__is_debugger_present_hook  = &__is_debugger_present_flag;` when it connects (and reverts when it disconnects). That allows for both the fast and precise integrated implementation with fallback to the slower implementation.

Note, inlining `is_debugger_present` was never expected during the wg21 discussions. And it was very much expected that it would not be inlined.

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