From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89488 invoked by alias); 10 Dec 2018 18:55:04 -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 89471 invoked by uid 89); 10 Dec 2018 18:55:03 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=1.3 required=5.0 tests=BAYES_50,KAM_NUMSUBJECT,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=H*f:sk:B6beozo, H*f:sk:2f4c983, H*f:CAKOQZ8y, H*f:sk:rbMPS3y 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 18:55:02 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4CBA045BDA; Mon, 10 Dec 2018 18:55:01 +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 DAC7D5C1B4; Mon, 10 Dec 2018 18:55:00 +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 wBAIsvJW030191; Mon, 10 Dec 2018 19:54:57 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id wBAIsppH030190; Mon, 10 Dec 2018 19:54:51 +0100 Date: Mon, 10 Dec 2018 18:55:00 -0000 From: Jakub Jelinek To: Ian Lance Taylor Cc: Nick Clifton , Michael Matz , "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: <20181210185451.GE12380@tucnak> Reply-To: Jakub Jelinek References: <2f4c983b-494f-93ba-d6c6-1fe0a9730a76@redhat.com> <9e739bbc-38a2-c3b1-3b2b-f8de4b755d47@redhat.com> <20181210151846.GB12380@tucnak> <0af34ffd-e894-2803-7c4e-eac4d9ffb385@redhat.com> <20181210153538.GC12380@tucnak> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg00593.txt.bz2 On Mon, Dec 10, 2018 at 10:20:24AM -0800, Ian Lance Taylor wrote: > > I think it is a bad idea to use the same macro and value for both the > > recursion limit and essentially stack limit. For the latter, it should > > actually compute expected stack size > > (i.e. di.num_comps * sizeof (*di.comps) + di.num_subs * sizeof (*di.subs)) > > and rather than just giving up should say that memory up to 64KB this > > way will be handled via alloca, more through say mmap (I'd avoid malloc > > because some users are using these APIs in cases where malloc isn't usable). > > And have only much larger limit, like say 1MB for these arrays on which to > > give up. > > That makes sense. > > We've wanted to avoid malloc in this code because some programs call > the demangler from a signal handler. But using mmap should be fine in > practice. mmap is not available everywhere, but we could just have a smaller limit on how big mangled names we handle on targets where mmap isn't available or if it fails. And, the other option is just try to parse the string without doing all the processing first and compute (perhaps upper bound) on how many components and substitutions we need. Many components have longish names, or numbers, etc. so the 2 * strlen is really very upper bound and strlen for number of substitutions too. Jakub