From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9094 invoked by alias); 10 Dec 2018 15:18:57 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 9050 invoked by uid 89); 10 Dec 2018 15:18:56 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,KAM_NUMSUBJECT,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=toward, H*f:sk:B6beozo, H*f:sk:2f4c983, H*f:sk:fca558b X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 10 Dec 2018 15:18:55 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7F9C1C058CB3; Mon, 10 Dec 2018 15:18:54 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-117-214.ams2.redhat.com [10.36.117.214]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 435E618ED8; Mon, 10 Dec 2018 15:18:50 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id wBAFIlKJ022633; Mon, 10 Dec 2018 16:18:48 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id wBAFIkx8022632; Mon, 10 Dec 2018 16:18:46 +0100 Date: Mon, 10 Dec 2018 15:18:00 -0000 From: Jakub Jelinek To: Nick Clifton Cc: Michael Matz , Ian Lance Taylor , "H.J. Lu" , Pedro Alves , Richard Guenther , sgayou@redhat.com, Tom Tromey , GCC Patches , Binutils , Jason Merrill Subject: Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536 Message-ID: <20181210151846.GB12380@tucnak> Reply-To: Jakub Jelinek References: <736e8303-b724-f96d-54f5-46bff99fa34d@redhat.com> <57d33aa7-4e37-a09c-4bdc-974b5f654d33@redhat.com> <2f4c983b-494f-93ba-d6c6-1fe0a9730a76@redhat.com> <9e739bbc-38a2-c3b1-3b2b-f8de4b755d47@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9e739bbc-38a2-c3b1-3b2b-f8de4b755d47@redhat.com> User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg00581.txt.bz2 On Mon, Dec 10, 2018 at 03:12:53PM +0000, Nick Clifton wrote: > Hi Michael, > > > I think this points toward the limit being _much_ too low. > > Fair enough - several other people have said this as well. So > I have proposed an alternative patch instead. My current suggestion > is to raise the limit to 2048, which allows the libiberty patch to > pass. But do you have a feel for how much is a realistic limit ? For recursion limit I think that is fine. For just stack size limit, I think it is extremely small. I see that in the function it allocates on 64-bit 24 bytes times num_comps using alloca, so 48 bytes per character in the mangled name, and a pointer for each character in the mangled name. That is 112KB per 2048 bytes long mangled name. Dunno how much stack can we expect to be usable. Jakub