From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id D5F023858C51 for ; Wed, 18 May 2022 11:16:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D5F023858C51 Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-206-1EzQefa6OpSDrnOY5rJztg-1; Wed, 18 May 2022 07:16:34 -0400 X-MC-Unique: 1EzQefa6OpSDrnOY5rJztg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 3D11E1C0F68B for ; Wed, 18 May 2022 11:16:34 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.89]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B731740CF8EE for ; Wed, 18 May 2022 11:16:33 +0000 (UTC) From: Florian Weimer To: libstdc++@gcc.gnu.org Subject: Bare metal C++ with a GNU/Linux toolchain Date: Wed, 18 May 2022 13:16:31 +0200 Message-ID: <87h75n6qgg.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2022 11:16:36 -0000 It seems that it is fairly straightforward to eliminate dependencies on libstdc++ if only a C++ subset is used (no exception handling, no RTTI, no operator new, etc.). But once you use abstract classes, you necessarily gain a reference to __cxa_pure_virtual. Would it be possible to document this symbol as interposable, so that developers can bring their own definition if they want? If yes, what would be the appropriate place for this? Thanks, Florian