Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536

[Jeff Law <law@redhat.com>]

On 12/10/18 8:34 AM, Jason Merrill wrote:
> 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...
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