public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: gcc-patches@gcc.gnu.org
Subject: [PATCH 0/3] mangler/demangler dogfooding
Date: Tue, 27 May 2014 11:57:00 -0000	[thread overview]
Message-ID: <1401191856-27585-1-git-send-email-palves@redhat.com> (raw)

There's been discussion on the GDB lists about demangler crashes
bringing down GDB.

Such demangler bugs should be fixed, of course.  Patch 2 in this
series fixes the one that is currently known.

But while GDB demangles all symbols in every file it loads, always, in
libstdc++, the demangler is only called in error situations, and then
only to demangle the few symbols that appear in the backtrace.  This
means that mangler/demangler bugs can easily escape undetected until
much later, when the user is trying to debug the program.

So we had a discussion in the gdb lists about whether there is
something that could be done to demangler testing to make it more
effective in catching bugs that GDB would catch.  Ideas in progress so
far:

- Just throw more symbols at it once in a while.

We'd like to try "demangling the world" once in a while.  That is,
demangle all symbols in a distro.  Florian Weimer did this with the
ELF symbols in Fedora 20 and rawhide, and didn't get any crashes,
which is reassuring.  We haven't yet tried extracting and demangling
all DWARF symbols, but we'd like to get there too.

- Throw pseudo-random symbols at the demangler.

That is, make it more robust wrt to invalid input.  Gary wrote a fuzzy
tester, and it already caught a few crashes.

- Teach g++ itself to try to demangle any symbol it generates/mangles

... when checking is enabled in the build.

The idea here is validate the mangling/demangling as close as possible
to the generator as possible.  Patch 3 in this series implements this.
This is my favorite approach, as this catches demangler crashes much
earlier in the cycle, when building libstdc++ and friends, and when
running g++'s testsuite, rather than much later in production when the
user is trying to debug the code, or the program tries to generate a
backtrace.  Both libstdc++ and the testsuite include a good set of
tricky symbols to demangle, and the latter naturally includes all sort
of random, weird, code full of corner cases.  And, I assume g++
maintainers once in a while run WIP g++ through some piles of very
complicated C++ code.

Patch 2 fixes the demangler crashes I got when running the testsuite
with patch 3 installed.

And then patch 1 fixes crashes in the demangler debug that I got while
I was writing patch 2.

Pedro Alves (3):
  Fix demangler testsuite crashes with CP_DEMANGLE_DEBUG defined
  PR other/61321 - demangler crash on casts in template parameters
  mangler/demangler dogfooding

 gcc/cp/mangle.c                       | 30 ++++++++++++++++++++++++
 include/demangle.h                    |  4 ++++
 libiberty/cp-demangle.c               | 43 ++++++++++++++++++++++++++++-------
 libiberty/cp-demint.c                 |  1 +
 libiberty/testsuite/demangle-expected | 23 +++++++++++++++++++
 5 files changed, 93 insertions(+), 8 deletions(-)

-- 
1.9.0

             reply	other threads:[~2014-05-27 11:57 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-27 11:57 Pedro Alves [this message]
2014-05-27 11:57 ` [PATCH 3/3] " Pedro Alves
2014-05-27 18:16   ` Mike Stump
2014-05-28 22:31   ` [PATCH v2 " Pedro Alves
2014-06-02 13:38     ` Jason Merrill
2014-05-27 11:57 ` [PATCH 1/3] Fix demangler testsuite crashes with CP_DEMANGLE_DEBUG defined Pedro Alves
2014-05-27 13:56   ` Ian Lance Taylor
2014-05-28 22:20     ` Pedro Alves
2014-05-27 11:57 ` [PATCH 2/3] PR other/61321 - demangler crash on casts in template parameters Pedro Alves
2014-05-30 17:37   ` Cary Coutant
2014-05-30 18:05     ` Ian Lance Taylor
2014-05-30 19:00       ` Pedro Alves
2014-06-02 13:42   ` Jason Merrill
2014-07-24 22:44     ` Cary Coutant
2014-07-25  9:55       ` Pedro Alves
2014-10-13 18:46         ` Cary Coutant
2014-11-10 21:45           ` Cary Coutant
2014-11-12 15:16             ` Jason Merrill

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=1401191856-27585-1-git-send-email-palves@redhat.com \
    --to=palves@redhat.com \
    --cc=gcc-patches@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).