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 <ni...@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.
Jakub
