libbacktrace integration for _GLIBCXX_DEBUG mode

Jonathan Wakely jwakely@redhat.com
Fri Dec 21 21:03:00 GMT 2018


On 21/12/18 22:47 +0200, Ville Voutilainen wrote:
>On Fri, 21 Dec 2018 at 22:35, Jonathan Wakely <jwakely@redhat.com> 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."

Yes, but if you happen to install libbacktrace headers, the behaviour
for users building their own code changes. I agree that if you install
those headers, it's probably for a reason, but it might be a different
reason to "so that libstdc++ prints better backtraces".

>> 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!

Yes, I agree that making it available via a more explicit opt-in would
be good. Maybe require users to define _GLIBCXX_DEBUG_BACKTRACE as well
as _GLIBCXX_DEBUG, or something like that.




More information about the Libstdc++ mailing list