Date: Mon, 13 Feb 2023 17:47:27 +0000
> But we have a suggested relation between is_debugger_present and other
> debugging functions. Should from this replaceable idea follow that e.g.
> breakpoint() should also be replaceable?
P2546 proposes 3 functions: breakpoint(), is_debugger_present(), and breakpoint_if_debugging(). Breakpoint() can usually be implemented in terms of inline asm or compiler intrinsics, and usually only requires knowledge of the instruction set of the target. It doesn't directly interact with is_debugger_present. Breakpoint_if_debugging() is specified in terms of is_debugger_present(), so replacing is_debugger_present() will also affect the behavior of breakpoint_if_debugging().
> -----Original Message-----
> From: Daniel Krügler <daniel.kruegler_at_gmail.com>
> Sent: Monday, February 13, 2023 12:49 AM
> To: lib-ext_at_[hidden]
> Cc: Ben Craig <ben.craig_at_ni.com>; ISO C++ Tooling Study Group
> <sg15_at_[hidden]>; René Ferdinand Rivera Morell
> <grafikrobot_at_[hidden]>
> Subject: [EXTERNAL] Re: [isocpp-lib-ext] Debugging support and freestanding
> (P2546)
>
> Am Mo., 13. Feb. 2023 um 06:11 Uhr schrieb René Ferdinand Rivera Morell via
> Lib-Ext <lib-ext_at_[hidden]ocpp.org>:
> >
> > On Sun, Feb 12, 2023 at 4:56 PM René Ferdinand Rivera Morell
> > <grafikrobot_at_[hidden]> wrote:
> > >
> > > On Sun, Feb 12, 2023 at 3:04 PM Ben Craig <ben.craig_at_ni.com> wrote:
> > > >
> > > > If you want is_debugger_present to be a portable spelling that enables
> the user to implement it, then I think what you want is a replaceable function,
> like operator new / delete. I think I could support the idea of always having
> an is_debugger_present entry with an always false response, but allow the
> user to replace that implementation with a good one. This could allow
> portable spelling for libraries, portable implementations for freestanding
> toolchain vendors, and portably plugging in to the facility by users.
> > >
> > > That is a really good idea. I like it! It could easily be done as a
> > > followup paper also. Since it's just adding to the
> > > [replacement.functions]. Not sure when the e-polls are getting done.
> > > But I can write up that additional paper, and maybe you can co-author?
> >
> > Here's a rough draft of that idea
> >
> <https://urldefense.com/v3/__https://isocpp.org/files/papers/D2810R0.ht
> ml__;!!FbZ0ZwI3Qg!vniOW7ornAFds0qS0h57EUzyJkm9t_N6CBt67HU6UhVM
> hGy0jgjwXRuWy_4ej4e-pHtDijKSVS1AznEoNhLLSA$ >.
>
> But we have a suggested relation between is_debugger_present and other
> debugging functions. Should from this replaceable idea follow that e.g.
> breakpoint() should also be replaceable?
>
> - Daniel
INTERNAL - NI CONFIDENTIAL
> debugging functions. Should from this replaceable idea follow that e.g.
> breakpoint() should also be replaceable?
P2546 proposes 3 functions: breakpoint(), is_debugger_present(), and breakpoint_if_debugging(). Breakpoint() can usually be implemented in terms of inline asm or compiler intrinsics, and usually only requires knowledge of the instruction set of the target. It doesn't directly interact with is_debugger_present. Breakpoint_if_debugging() is specified in terms of is_debugger_present(), so replacing is_debugger_present() will also affect the behavior of breakpoint_if_debugging().
> -----Original Message-----
> From: Daniel Krügler <daniel.kruegler_at_gmail.com>
> Sent: Monday, February 13, 2023 12:49 AM
> To: lib-ext_at_[hidden]
> Cc: Ben Craig <ben.craig_at_ni.com>; ISO C++ Tooling Study Group
> <sg15_at_[hidden]>; René Ferdinand Rivera Morell
> <grafikrobot_at_[hidden]>
> Subject: [EXTERNAL] Re: [isocpp-lib-ext] Debugging support and freestanding
> (P2546)
>
> Am Mo., 13. Feb. 2023 um 06:11 Uhr schrieb René Ferdinand Rivera Morell via
> Lib-Ext <lib-ext_at_[hidden]ocpp.org>:
> >
> > On Sun, Feb 12, 2023 at 4:56 PM René Ferdinand Rivera Morell
> > <grafikrobot_at_[hidden]> wrote:
> > >
> > > On Sun, Feb 12, 2023 at 3:04 PM Ben Craig <ben.craig_at_ni.com> wrote:
> > > >
> > > > If you want is_debugger_present to be a portable spelling that enables
> the user to implement it, then I think what you want is a replaceable function,
> like operator new / delete. I think I could support the idea of always having
> an is_debugger_present entry with an always false response, but allow the
> user to replace that implementation with a good one. This could allow
> portable spelling for libraries, portable implementations for freestanding
> toolchain vendors, and portably plugging in to the facility by users.
> > >
> > > That is a really good idea. I like it! It could easily be done as a
> > > followup paper also. Since it's just adding to the
> > > [replacement.functions]. Not sure when the e-polls are getting done.
> > > But I can write up that additional paper, and maybe you can co-author?
> >
> > Here's a rough draft of that idea
> >
> <https://urldefense.com/v3/__https://isocpp.org/files/papers/D2810R0.ht
> ml__;!!FbZ0ZwI3Qg!vniOW7ornAFds0qS0h57EUzyJkm9t_N6CBt67HU6UhVM
> hGy0jgjwXRuWy_4ej4e-pHtDijKSVS1AznEoNhLLSA$ >.
>
> But we have a suggested relation between is_debugger_present and other
> debugging functions. Should from this replaceable idea follow that e.g.
> breakpoint() should also be replaceable?
>
> - Daniel
INTERNAL - NI CONFIDENTIAL
Received on 2023-02-13 17:47:33