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: Jason Merrill <jason at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Michael Matz <matz at suse dot de>, Nick Clifton <nickc at redhat dot com>, Ian Lance Taylor <iant at google dot com>, "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 10:34:05 -0500
- Subject: Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536
- References: <CAKOQZ8zspME4gzoRw4xgFcShoqeUfp_e=Og=4S-yKn4EehokeA@mail.gmail.com> <736e8303-b724-f96d-54f5-46bff99fa34d@redhat.com> <57d33aa7-4e37-a09c-4bdc-974b5f654d33@redhat.com> <c7c959ca-b8bf-bd3e-a65d-bb274a3118d3@redhat.com> <fca558b7-9ed3-76d0-176c-03f64790e3f1@redhat.com> <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> <20181210151020.GA12380@tucnak>
On Mon, Dec 10, 2018 at 10:10 AM Jakub Jelinek <jakub@redhat.com> wrote:
> On Mon, Dec 10, 2018 at 02:52:39PM +0000, Michael Matz wrote:
> > On Fri, 7 Dec 2018, H.J. Lu wrote:
> >
> > > > > On Thu, Dec 6, 2018 at 3:12 AM Nick Clifton <nickc@redhat.com> wrote:
> > > > > >
> > > > > > Is the patch OK with you ?
> > > > >
> > > >
> > > > This caused:
> > > >
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409
> > > >
> > >
> > > Here is the fix. OK for trunk?
> >
> > I think this points toward the limit being _much_ too low. With template
> > meta programming you easily get these mangled names, it's not even a
> > particularly long one. But I'm wondering a bit, without tracing the
> > demangler, just looking at the symbol name and demangled result I don't
> > readily see where the depth of recursion really is more than 1024, are
> > there perhaps some recursion_level-- statements skipped?
>
> That is because the recursion_level limit isn't hit in this case at all (far
> from it).
>
> What breaks it is this:
>
> /* PR 87675 - Check for a mangled string that is so long
> that we do not have enough stack space to demangle it. */
> if (((options & DMGL_NO_RECURSE_LIMIT) == 0)
> /* This check is a bit arbitrary, since what we really want to do is to
> compare the sizes of the di.comps and di.subs arrays against the
> amount of stack space remaining. But there is no portable way to do
> this, so instead we use the recursion limit as a guide to the maximum
> size of the arrays. */
> && (unsigned long) di.num_comps > DEMANGLE_RECURSION_LIMIT)
> {
> /* FIXME: We need a way to indicate that a stack limit has been reached. */
> return 0;
> }
> where di.num_comps is just strlen (mangled) * 2. Without any analysis
> whatsoever, bumping the "recursion" limit will just mean we can process 1.5
> times long names. Either we need more precise analysis on what we are
> looking for (how big arrays we'll need) or it needs to be an independent
> limit and certainly should allow say 10KB symbols too if they are
> reasonable.
If the problem is alloca, we could avoid using alloca if the size
passes a threshold. Perhaps even use a better data structure than a
preallocated array based on a guess about the number of components...
Jason