From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id B8C553858036 for ; Thu, 4 Nov 2021 23:44:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B8C553858036 Received: from mail-ua1-f71.google.com (mail-ua1-f71.google.com [209.85.222.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-182-7nk3N_CnNcStHvfZDvMqxQ-1; Thu, 04 Nov 2021 19:44:28 -0400 X-MC-Unique: 7nk3N_CnNcStHvfZDvMqxQ-1 Received: by mail-ua1-f71.google.com with SMTP id j29-20020ab0185d000000b002cbb3c4660bso3661359uag.23 for ; Thu, 04 Nov 2021 16:44:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NAMAMc6K8TqAlLlZqR+IRhLD1ROJhyxE3wrAt66VoxM=; b=7O4e7sacsJgMGUMrY/Pcd24SjNJMRRngHJK/M9NjObJoV4c9+5ueFke5f1lHNPZA71 7wBiVyuGSCojF7icf3XXDT1RjP95XGLczSrsqXkoo8pQJcN8Xbjwik1V51855YYVzuXr c18pazPz36n2/zFiHQecRSnz2UjVJpi2Q3BlrLNFiY0DpXeqOFusyQFYigFZhAfEwqyb XnUSbnkKZvSWJSxxY2V0/0WNxZZmbdzjGML1uISVjauOdrNiF0+fO22sxoFuUG7luW01 US1FIlbiH/a3R7MZCI/5ZjqCIRKjftkSXv/xwWvkfs/NR6HAhV/AMLSdg654ttqyN5jA BqLA== X-Gm-Message-State: AOAM5334cJ6VZ00v/HjZT1PnAWy/ROPrh16s+OHyljjrwBzXmX8Zbzp5 VCVHEA1RRWFGUuugdw8OTvlyrP64SVb3fDHJZI+IYwFDLo1VtLxChSSm6gtzfRpLllRPqqAJyMP 9I0FOf+0XEROKEhLEqPaTRxwr609Klic= X-Received: by 2002:a05:6102:3053:: with SMTP id w19mr68520247vsa.2.1636069467603; Thu, 04 Nov 2021 16:44:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwxl61IEAoAlLOQjWA2wk+6wdgrZ9aHbpXRMKr9xI3zm6ALgQWiHOjlRXlyZnAqSuiEd4FlQWfdJsy8P5IMuOY= X-Received: by 2002:a05:6102:3053:: with SMTP id w19mr68520217vsa.2.1636069467406; Thu, 04 Nov 2021 16:44:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Thu, 4 Nov 2021 23:44:16 +0000 Message-ID: Subject: Re: [PATCH] print extended assertion failures to stderr To: Jay Feldblum Cc: "libstdc++" , gcc Patches X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=unavailable autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2021 23:44:31 -0000 On Thu, 4 Nov 2021 at 11:30, Jonathan Wakely wrote: > > > On Wed, 27 Oct 2021 at 09:27, Jay Feldblum via Libstdc++ < > libstdc++@gcc.gnu.org> wrote: > >> From: yfeldblum >> >> The stdout stream is reserved for output intentionally produced by the >> application. Assertion failures and other forms of logging must be >> emitted to stderr, not to stdout. >> >> It is common for testing and monitoring infrastructure to scan stderr >> for errors, such as for assertion failures, and to collect or retain >> them for analysis or observation. It is a norm that assertion failures >> match this expectation in practice. >> >> While `__builtin_fprintf` is available as a builtin, there is no >> equivalent builtin for `stderr`. The only option in practice is to use >> the macro `stderr`, which requires `#include `. It is desired >> not to add such an include to `bits/c++config` so the solution is to >> write and export a function which may be called by `bits/c++config`. >> >> This is expected to be API-compatible and ABI-compatible with caveats. >> Code compiled against an earlier libstdc++ will work when linked into a >> later libstdc++ but the stream to which assertion failures are logged is >> anybody's guess, and in practice will be determined by the link line and >> the choice of linker. This fix targets builds for which all C++ code is >> built against a libstdc++ with the fix. >> > > Thanks for the patch! Comments below. > > > >> >> Alternatives: >> * This, which is the smallest change. >> * This, but also defining symbols `std::__stdin` and `std::__stdout` for >> completeness. >> * Define a symbol like `std::__printf_stderr` which prints any message >> with any formatting to stderr, just as `std::printf` does to stdout, >> and call that from `std::__replacement_assert` instead of calling >> `__builtin_printf`. >> * Move `std::__replacement_assert` into libstdc++.so and no longer mark >> it as weak. This allows an application with some parts built against a >> previous libstdc++ to guarantee that the fix will be applied at least >> to the parts that are built against a libstdc++ containing the fix. >> > Actually it wouldn't guarantee it even for the new parts. Any objects built against the old libstdc++ headers might contain a definition of std::__replacement_assert, and that would get used in preference to the one in libstdc++.so, even for the new objects built against the new headers. To make it work we could change the signature of the function (e.g. use long or unsigned instead of int for the line number) so that code compiled against the new headers look for a new symbol, and never use one in old objects.