This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: 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 Guenther <richard dot guenther at gmail dot com>, sgayou at redhat dot com, Tom Tromey <tom at tromey dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Binutils <binutils at sourceware dot org>, Jason Merrill <jason at redhat dot com>
- Date: Mon, 10 Dec 2018 19:54:51 +0100
- Subject: Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536
- References: <2f4c983b-494f-93ba-d6c6-1fe0a9730a76@redhat.com> <CAKOQZ8y=B6beozokJ2tdAAkVDVue08ogehMP7TAXvrPzdz9MuQ@mail.gmail.com> <CAMe9rOomd2E3C03CxTXyTRkq6HG32OX+rbMPS3y6dcEWmwaMYg@mail.gmail.com> <CAMe9rOokMpaAUFk0rcYTTUQTQhEMn-VQetXfiDTDXYdTXZEJTA@mail.gmail.com> <alpine.LSU.2.21.1812101442470.5354@wotan.suse.de> <9e739bbc-38a2-c3b1-3b2b-f8de4b755d47@redhat.com> <20181210151846.GB12380@tucnak> <0af34ffd-e894-2803-7c4e-eac4d9ffb385@redhat.com> <20181210153538.GC12380@tucnak> <CAKOQZ8zJA_bjuZdq+g2rUoQf_EgihsRR5WanG7EuwWbmP=+xGA@mail.gmail.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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.
Jakub