[PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536

Jeff Law law@redhat.com
Tue Dec 11 00:33:00 GMT 2018


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



More information about the Binutils mailing list