From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-492126-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 45043 invoked by alias); 11 Dec 2018 15:07:18 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 45017 invoked by uid 89); 11 Dec 2018 15:07:18 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=0.5 required=5.0 tests=BAYES_20,KAM_NUMSUBJECT,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=H*f:sk:B6beozo, H*f:CAKOQZ8y, H*f:sk:2f4c983, 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; Tue, 11 Dec 2018 15:07:17 +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 0AC06308A94E;	Tue, 11 Dec 2018 15:07:16 +0000 (UTC)
Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4])	by smtp.corp.redhat.com (Postfix) with ESMTP id 5F0246015E;	Tue, 11 Dec 2018 15:07:13 +0000 (UTC)
Subject: Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536
To: Ian Lance Taylor <iant@google.com>
References: <c7c959ca-b8bf-bd3e-a65d-bb274a3118d3@redhat.com> <fca558b7-9ed3-76d0-176c-03f64790e3f1@redhat.com> <2f4c983b-494f-93ba-d6c6-1fe0a9730a76@redhat.com> <CAKOQZ8y=B6beozokJ2tdAAkVDVue08ogehMP7TAXvrPzdz9MuQ@mail.gmail.com> <CAMe9rOomd2E3C03CxTXyTRkq6HG32OX+rbMPS3y6dcEWmwaMYg@mail.gmail.com> <CAMe9rOokMpaAUFk0rcYTTUQTQhEMn-VQetXfiDTDXYdTXZEJTA@mail.gmail.com> <alpine.LSU.2.21.1812101442470.5354@wotan.suse.de> <20181210151020.GA12380@tucnak> <CADzB+2nX8UO94EjRiSegxFXBKwb7qmYLLpSjbJmXkZNo20M7Lg@mail.gmail.com> <2b97a775-ed9a-9bd2-e574-52b679f464c7@redhat.com> <20181211065804.GH12380@tucnak> <1530d100-1161-3241-8f5c-59aaa7b3ba9f@redhat.com> <CAKOQZ8xym5JhwL7wTWDy5VMEPcTBu-YTahKpcm5-2sLe=dXyGg@mail.gmail.com>
Cc: Jakub Jelinek <jakub@redhat.com>, Jeff Law <law@redhat.com>, Jason Merrill <jason@redhat.com>, Michael Matz <matz@suse.de>, Nick Clifton <nickc@redhat.com>, "H.J. Lu" <hjl.tools@gmail.com>, Richard Guenther <richard.guenther@gmail.com>, sgayou@redhat.com, Tom Tromey <tom@tromey.com>, gcc-patches <gcc-patches@gcc.gnu.org>, Binutils <binutils@sourceware.org>
From: Pedro Alves <palves@redhat.com>
Message-ID: <b1651b60-90d8-8f1f-e99e-cf458814da10@redhat.com>
Date: Tue, 11 Dec 2018 15:07:00 -0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <CAKOQZ8xym5JhwL7wTWDy5VMEPcTBu-YTahKpcm5-2sLe=dXyGg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-SW-Source: 2018-12/txt/msg00700.txt.bz2

On 12/11/2018 02:25 PM, Ian Lance Taylor wrote:
> On Tue, Dec 11, 2018 at 3:05 AM Pedro Alves <palves@redhat.com> wrote:

>> Ian earlier mentioned that we've wanted to avoid malloc because some
>> programs call the demangler from a signal handler, but it seems like
>> we already do, these functions already aren't safe to use from
>> signal handlers as is.  Where does the "we can't use malloc" idea
>> come from?  Is there some entry point that avoids
>> the malloc/realloc/free calls?
> 
> cplus_demangle_v3_callback and cplus_demangle_print_callback.

Ah, gotcha.  Thanks!  Interesting.

Pedro Alves