This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536
- From: Jason Merrill <jason at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Ian Lance Taylor <iant at google dot com>, Nick Clifton <nickc at redhat dot com>, Michael Matz <matz at suse dot de>, "H.J. Lu" <hjl dot tools at gmail dot com>, Pedro Alves <palves at redhat dot com>, Richard Biener <richard dot guenther at gmail dot com>, Scott Gayou <sgayou at redhat dot com>, Tom Tromey <tom at tromey dot com>, gcc-patches List <gcc-patches at gcc dot gnu dot org>, Binutils <binutils at sourceware dot org>
- Date: Mon, 10 Dec 2018 18:47:31 -0500
- Subject: Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536
- References: <firstname.lastname@example.org> <CAKOQZ8y=B6beozokJ2tdAAkVDVue08ogehMP7TAXvrPzdz9MuQ@mail.gmail.com> <CAMe9rOomd2E3C03CxTXyTRkq6HG32OX+rbMPS3y6dcEWmwaMYg@mail.gmail.com> <CAMe9rOokMpaAUFk0rcYTTUQTQhEMn-VQetXfiDTDXYdTXZEJTA@mail.gmail.com> <alpine.LSU.email@example.com> <firstname.lastname@example.org> <20181210151846.GB12380@tucnak> <email@example.com> <20181210153538.GC12380@tucnak> <CAKOQZ8zJA_bjuZdq+g2rUoQf_EgihsRR5WanG7EuwWbmP=+xGA@mail.gmail.com> <20181210185451.GE12380@tucnak>
On Mon, Dec 10, 2018 at 1:55 PM Jakub Jelinek <firstname.lastname@example.org> wrote:
> On Mon, Dec 10, 2018 at 10:20:24AM -0800, Ian Lance Taylor wrote:
> > > I think it is a bad idea to use the same macro and value for both the
> > > recursion limit and essentially stack limit. For the latter, it should
> > > actually compute expected stack size
> > > (i.e. di.num_comps * sizeof (*di.comps) + di.num_subs * sizeof (*di.subs))
> > > and rather than just giving up should say that memory up to 64KB this
> > > way will be handled via alloca, more through say mmap (I'd avoid malloc
> > > because some users are using these APIs in cases where malloc isn't usable).
> > > And have only much larger limit, like say 1MB for these arrays on which to
> > > give up.
> > That makes sense.
> > We've wanted to avoid malloc in this code because some programs call
> > the demangler from a signal handler. But using mmap should be fine in
> > practice.
> mmap is not available everywhere, but we could just have a smaller limit
> on how big mangled names we handle on targets where mmap isn't available or
> if it fails.
> And, the other option is just try to parse the string without doing all the
> processing first and compute (perhaps upper bound) on how many components
> and substitutions we need. Many components have longish names, or numbers,
> etc. so the 2 * strlen is really very upper bound and strlen for number of
> substitutions too.
Or, in that situation, we could put an upper bound on the number of
components and substitutions, and fail if we end up needing more than