On Fri, 29 Aug 2025 at 19:45, Iain Sandoe <[email protected]> wrote: > > > > > On 29 Aug 2025, at 15:55, Jonathan Wakely <[email protected]> wrote: > > > > On Fri, 29 Aug 2025 at 15:19, Rainer Orth <[email protected]> > > wrote: > >> > >> Hi Jonathan, > >>> > >>>> The src/c++26/debugging.cc file defines a global volatile int which can > >>>> be set by debuggers to indicate when they are attached and detached from > >>>> a running process. This allows std::is_debugger_present() to give a > >>>> reliable answer, and additionally allows a debugger to choose how > >>>> std::breakpoint() should behave. Setting the global to a positive value > >>>> will cause std::breakpoint() to use that value as an argument to > >>>> std::raise, so debuggers that prefer SIGABRT for breakpoints can select > >>>> that. By default std::breakpoint() will use a platform-specific action > >>>> such as the INT3 instruction on x86, or GCC's __builtin_trap(). > >>> > >>> this patch broke Solaris/x86 bootstrap with /bin/as: > >> > >> it also broke bootstrap on macOS 11, 10.11: > > > > I'll test a patch for both issues. > > r16-3446 bootstrapped OK on x86_64 macOS12, but adding the header will be > harmless there (my weekly tests across a wider range of OS versions will pick > up whatever is committed before end of Sat).
Sorry for missing the deadline, I had family stuff to do yesterday. I've pushed a patch that should fix Solaris and Darwin, but didn't test it on either of them. > > ---- > > I will look into implementing the is_debugger_present () as per the Apple > Developer suggested mechanism (and also consider the mechanism you’ve > documented for Linux). Thanks. I wouldn't spend any time trying to replicate the "is the tracer a known debugger?" functionality, as I'm not sure we'll end up keeping that. Some people have argued that we should treat any tracer as a debugger, and I'm somewhat persuaded that it's less fragile and more consistent to do that.
