From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 125598 invoked by alias); 30 Nov 2018 10:27:03 -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 125054 invoked by uid 89); 30 Nov 2018 10:27:03 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy= 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; Fri, 30 Nov 2018 10:27:02 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DE0A989ADC; Fri, 30 Nov 2018 10:27:00 +0000 (UTC) Received: from [10.36.116.107] (ovpn-116-107.ams2.redhat.com [10.36.116.107]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6BEB4600CC; Fri, 30 Nov 2018 10:26:59 +0000 (UTC) To: Jakub Jelinek Cc: ian@airs.com, gcc-patches@gcc.gnu.org, binutils@sourceware.org, matz@gcc.gnu.org, sgayou@redhat.com, jason@redhat.com References: <87muprdko7.fsf@redhat.com> <20181130084211.GX12380@tucnak> From: Nick Clifton Openpgp: preference=signencrypt Subject: Re: RFA/RFC: Add stack recursion limit to libiberty's demangler Message-ID: <173817ca-0aa0-e1a2-6725-37e079ead545@redhat.com> Date: Fri, 30 Nov 2018 10:27:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <20181130084211.GX12380@tucnak> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-11/txt/msg02547.txt.bz2 Hi Jakub, >> Also - Tom and Pedro have raised the issue that the patch introduces >> a new static variable to the library that is not thread safe. I am >> not sure of the best way to address this problem. Possibly the >> variable could be made thread local ? Are there any other static > > Please don't. OK. :-) > Most of the demangler functions pass around a pointer to a struct with > context, can't this be added in there? Not without modifying the current demangling interface. The problem is that the context structure is created for each invocation of a demangling function (from outside the library), and no state is preserved across demangling calls. Thus in order to have a recursion limit which is configurable by the caller, you either need to have a global variable or else extend the demangling interface to include a recursion limit parameter. I did consider just having a fixed limit, that the user cannot change, but I thought that this might be rejected by reviewers. (On the grounds that different limits are appropriate to different execution environments). Note - enabling or disabling the recursion limit is controlled by a separate feature of the proposed patch, ie the new DMGL_RECURSE_LIMIT flag in the options field of the cplus_demangleXXX() functions. But there is not enough room in the options field to also include a recursion limit value. Cheers Nick