On 12/10/18 8:34 AM, Jason Merrill wrote: > On Mon, Dec 10, 2018 at 10:10 AM Jakub Jelinek <ja...@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 <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. > > 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... Actually I would strongly suggest avoiding alloca completely. This isn't particularly performance sensitive code and alloca can be abused in all kinds of interesting ways.
jeff