From: "François Dumont" <frs.dumont@gmail.com>
To: Jonathan Wakely <jwakely@redhat.com>
Cc: "libstdc++@gcc.gnu.org" <libstdc++@gcc.gnu.org>,
gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Add _GLIBCXX_DEBUG backtrace generation
Date: Wed, 31 Aug 2022 21:33:24 +0200 [thread overview]
Message-ID: <542e3e43-fc03-a575-7d00-6dd00c28146b@gmail.com> (raw)
In-Reply-To: <CACb0b4mK0gcbp7zbntvpxHXS1+3wFawNOAtHEe3pqC5UbqWZXw@mail.gmail.com>
On 31/08/22 12:11, Jonathan Wakely wrote:
> On Wed, 31 Aug 2022 at 06:05, François Dumont <frs.dumont@gmail.com> wrote:
>> After a second thought here is an even cleaner version. No more function
>> rename, current pretty_print is fine.
>>
>> libstdc++: [_GLIBCXX_DEBUG] Add backtrace generation on demand
>>
>> Add _GLIBCXX_DEBUG_BACKTRACE macro to activate backtrace
>> generation on
>> _GLIBCXX_DEBUG assertions. Prerequisite is to have configure the
>> lib with:
>>
>> --enable-libstdcxx-backtrace=yes
>>
>> libstdc++-v3/ChangeLog:
>>
>> * include/debug/formatter.h
>> [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_state): Declare.
>> [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_create_state): Declare.
>> [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_full_callback): Define.
>> [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_error_callback): Define.
>> [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_full_func): Define.
>> [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_full): Declare.
>> [_GLIBCXX_HAVE_STACKTRACE](_Error_formatter::_M_backtrace_state): New.
>> [_GLIBCXX_HAVE_STACKTRACE](_Error_formatter::_M_backtrace_full): New.
>> * src/c++11/debug.cc
>> [_GLIBCXX_HAVE_STACKTRACE](print_backtrace): New.
>> (_Error_formatter::_M_error()): Adapt.
>> * src/libbacktrace/Makefile.am: Add backtrace.c.
>> * src/libbacktrace/Makefile.in: Regenerate.
>> * src/libbacktrace/backtrace-rename.h (backtrace_full): New.
>> *
>> testsuite/23_containers/vector/debug/assign4_backtrace_neg.cc: New test.
>> * doc/xml/manual/debug_mode.xml: Document
>> _GLIBCXX_DEBUG_BACKTRACE.
>> * doc/xml/manual/using.xml: Likewise.
>> Ok to commit ?
> OK for trunk, thanks.
>
> The small change to print_raw in this patch makes me wonder whether
> that function is actually useful.
>
> It supports two modes, print with max precision, and print without.
> The only time we use it to print with max precision we pass a string
> of exactly the right length, so the precision is not needed (but the
> caller has to get the string length correct: if we increase _S_indent
> and do not increase the " " literal passed to print_raw, the
> effects would be wrong).
>
> Wouldn't it be better to just use fprintf directly when we want to
> print without precision, and use a minimum field width instead of
> precision for indenting? i.e. ...
>
> --- a/libstdc++-v3/src/c++11/debug.cc
> +++ b/libstdc++-v3/src/c++11/debug.cc
> @@ -608,15 +608,6 @@ namespace
> print_literal(PrintContext& ctx, const char(&word)[Length])
> { print_word(ctx, word, Length - 1); }
>
> - void
> - print_raw(PrintContext& ctx, const char* str, ptrdiff_t nbc = -1)
> - {
> - if (nbc >= 0)
> - ctx._M_column += fprintf(stderr, "%.*s", (int)nbc, str);
> - else
> - ctx._M_column += fprintf(stderr, "%s", str);
> - }
> -
> void
> print_word(PrintContext& ctx, const char* word, ptrdiff_t nbc = -1)
> {
> @@ -643,12 +634,9 @@ namespace
> || (ctx._M_column + visual_length < ctx._M_max_length)
> || (visual_length >= ctx._M_max_length && ctx._M_column == 1))
> {
> - // If this isn't the first line, indent
> + // If this isn't the first line, indent.
> if (ctx._M_column == 1 && !ctx._M_first_line)
> - {
> - const char spacing[PrintContext::_S_indent + 1] = " ";
> - print_raw(ctx, spacing, PrintContext::_S_indent);
> - }
> + ctx._M_column += fprintf(stderr, "%*c", PrintContext::_S_indent, ' ');
I did not know this syntax, it looks definitely better.
>
> int written = fprintf(stderr, "%.*s", (int)length, word);
>
> @@ -1112,7 +1100,7 @@ namespace __gnu_debug
> PrintContext ctx;
> if (_M_file)
> {
> - print_raw(ctx, _M_file);
> + ctx._M_column += fprintf(stderr, "%s", _M_file);
> print_literal(ctx, ":");
> go_to_next_line = true;
> }
>
Do you take care or you prefer I do ?
next prev parent reply other threads:[~2022-08-31 19:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-13 17:26 François Dumont
2022-08-04 20:46 ` François Dumont
2022-08-08 13:29 ` Jonathan Wakely
2022-08-09 8:07 ` François Dumont
2022-08-31 5:05 ` François Dumont
2022-08-31 10:11 ` Jonathan Wakely
2022-08-31 19:33 ` François Dumont [this message]
2022-08-31 20:07 ` Jonathan Wakely
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=542e3e43-fc03-a575-7d00-6dd00c28146b@gmail.com \
--to=frs.dumont@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jwakely@redhat.com \
--cc=libstdc++@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).