public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Nick Clifton <nickc@redhat.com>, ian@airs.com
Cc: gcc-patches@gcc.gnu.org, binutils@sourceware.org,
	matz@gcc.gnu.org, sgayou@redhat.com, jason@redhat.com
Subject: Re: RFA/RFC: Add stack recursion limit to libiberty's demangler
Date: Thu, 29 Nov 2018 18:20:00 -0000	[thread overview]
Message-ID: <8bf7952a-5cf1-27b9-e385-e1e12536bf3f@redhat.com> (raw)
In-Reply-To: <87sgzkszbh.fsf@redhat.com>

Hi Nick,

On 11/29/2018 03:01 PM, Nick Clifton wrote:
>  static struct demangle_component *
>  d_function_type (struct d_info *di)
>  {
> -  struct demangle_component *ret;
> +  static unsigned long recursion_level = 0;

Did you consider making this be a part of struct d_info instead?
IIRC, d_info is like a "this" pointer, passed around pretty
much everywhere.

I think going in the direction of making the demangler harder to use
in an efficient thread-safe manner is undesirable, even if the feature
is optional.  E.g., in GDB, loading big binaries, demangling is very high
in profiles, and so we've kicked around the desire to parallelize
it (e.g., by parallelizing the reading/interning of DSO files, instead of
reading all of them sequentially).  Having to synchronize access to the
demangler would be quite unfortunate.  If possible, it'd be great
to avoid making work toward that direction harder.  (Keeping in mind that
if this recursion detection feature is useful for binutils, then it should
also be useful for GDB.)

Thanks,
Pedro Alves

  parent reply	other threads:[~2018-11-29 18:20 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-29 15:01 Nick Clifton
2018-11-29 17:08 ` Scott Gayou
2018-11-30  8:42   ` Nick Clifton
2018-11-29 18:20 ` Pedro Alves [this message]
2018-11-29 22:18   ` Ian Lance Taylor
     [not found]   ` <87h8fza6fh.fsf@tromey.com>
     [not found]     ` <43e6c9e6-8249-bf56-aed8-90d0f771c567@redhat.com>
2018-11-30 11:58       ` Pedro Alves
2018-11-30  8:38 Nick Clifton
2018-11-30  8:42 ` Jakub Jelinek
2018-11-30 10:27   ` Nick Clifton
2018-11-30 13:46     ` Michael Matz
2018-11-30 14:57       ` Ian Lance Taylor
2018-12-02  0:49         ` Cary Coutant
2018-12-03 14:53           ` Nick Clifton
2018-12-03 22:00           ` Joseph Myers
2018-11-30 13:56     ` Ian Lance Taylor
2018-11-30 14:03       ` Jakub Jelinek

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=8bf7952a-5cf1-27b9-e385-e1e12536bf3f@redhat.com \
    --to=palves@redhat.com \
    --cc=binutils@sourceware.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=ian@airs.com \
    --cc=jason@redhat.com \
    --cc=matz@gcc.gnu.org \
    --cc=nickc@redhat.com \
    --cc=sgayou@redhat.com \
    /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).