This is the mail archive of the
mailing list for the GCC project.
Re: libbacktrace integration for _GLIBCXX_DEBUG mode
- From: Ville Voutilainen <ville dot voutilainen at gmail dot com>
- To: Jonathan Wakely <jwakely at redhat dot com>
- Cc: François Dumont <frs dot dumont at gmail dot com>, "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 21 Dec 2018 22:47:02 +0200
- Subject: Re: libbacktrace integration for _GLIBCXX_DEBUG mode
- References: <email@example.com> <20181221203504.GG3077@redhat.com>
On Fri, 21 Dec 2018 at 22:35, Jonathan Wakely <firstname.lastname@example.org> wrote:
> > I also explcitely define BACKTRACE_SUPPORTED to 0 to make sure
> >libstdc++ has no libbacktrace dependency after usual build.
> I'm concerned about the requirement to link to libbacktrace
> explicitly (which will break existing makefiles and build systems that
> currently use debug mode in testing).
But see what Francois wrote, "I also explcitely define
BACKTRACE_SUPPORTED to 0 to make sure
libstdc++ has no libbacktrace dependency after usual build."
> Also, some of the glibc team pointed out to me that running *any*
> extra code after undefined behaviour has been detected is a potential
> risk. The less that you do between detecting UB and calling abort(),
> the better. Giving the users more information is helpful, but comes
> with some additional risk.
Ditto. Having said those things, I think we need to figure out a good
way to provide this sensibly
as an opt-in. The backtrace support is bloody useful, and dovetails
into a possible Contracts-aware
implementation of our library, but I think we need to do some more
thought-work on this, thus I agree
that it's not stage3 material. I do think it's something that we need
to keep in mind, thanks
for working on it, Francois!