From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 3BD643857C44; Wed, 28 Sep 2022 15:14:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3BD643857C44 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1664378057; bh=OJhqY/7kXjo+CH8LTespPmlvNX5N/jrR4DdpxQAEJnw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=AQF9hiGHqjkE2lGVjx/+McMcYdBWDaOgEDRkph6iG3ZJSoYr2VxHuCaChA9XxENCO pTVPrc9AszGLbXTNfsc9K4BuETDDIzxX6RGSuGRUDnLFtD8f1dywcZ+swtiz8NnkWl HZQqs6DxLT/tBCupi7DwZuxzZw3ZKlUt3tA74Stg= From: "rdiezmail-gcc at yahoo dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions Date: Wed, 28 Sep 2022 15:14:16 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 4.9.3 X-Bugzilla-Keywords: patch X-Bugzilla-Severity: enhancement X-Bugzilla-Who: rdiezmail-gcc at yahoo dot de X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D68606 --- Comment #13 from R. Diez --- It is hard to automatically tell whether nobody else is using such a statically-allocated emergency buffer. In my case, I am using C++ exception= s, so the linker will probably always include the buffer. My patch makes sure that no emergency buffer is allocated. As long as your firmware does not run out of malloc RAM, C++ exceptions continue to work fi= ne. About implementing a proper solution (my patch is just a workaround): There= are probably guys who want to control the size of the emergency buffer, but for really constrained environments, I would like an option to disable it completely. As a bonus, the code that allocates and uses the emergency buffer could be optimised away too, but that is not critical for me. RAM / SRAM is often ti= ght, but Flash/program memory (where the code resides) tends to be much bigger. = So optimising the buffer away from RAM would be enough in most scenarios.=