From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) by sourceware.org (Postfix) with ESMTPS id 732EF3858402 for ; Mon, 10 Jan 2022 07:50:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 732EF3858402 Received: by mail-ed1-x534.google.com with SMTP id b7so20876720edj.9 for ; Sun, 09 Jan 2022 23:50:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=nLhq7rKTolRIig6VcXz0pr5bSiIspoX/V0/e8xMmDtM=; b=4h9O0RZj2LURc98RPIXyI89LY7VW6cNZBm/lVLPqqTSWxWAXHUB10jbUdCT9cJ/cXl bNpvaNEJffLargm04WGt4p+TUGnugA2Uu8imnraox3GaOmK/vjPc0A2ENjocmNVBIcUX PHoA75c9rlw+0eOarbBCVenx8JXkS9vZUgzWW5naWrFbrB+wRsrO/60jp49wTA69H5Da JNFsSq3yI+ru3dy3vASEbXZAG1qMSy07V7VWXSuTTakz25/BI9CkLK9gASTR3PePwKh+ CBFwxTnemXhYCtlsYMAC4wamRdnUz6Ta/5LWd9HR4RzcgnwHUfjmx/CfTx1Gh6TgmMxv TSsQ== X-Gm-Message-State: AOAM5321vipiFxNHa5ZrLckDdnRonjTLHDveWt+1JplaDD9oeqZM3eo4 Xs157PYj/ojxML7Mpsx3BqhSRuF1aRZOjAhDPGo= X-Google-Smtp-Source: ABdhPJyHIde9cND5LWbxov11rdPiNkj4xQYqCXDJaSlQaFGVIqbMZ/qBA95d5ph5TP6DpV/X9jX7Baa8S6to9co5nUU= X-Received: by 2002:a17:907:97d5:: with SMTP id js21mr58124837ejc.445.1641801045421; Sun, 09 Jan 2022 23:50:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Mon, 10 Jan 2022 08:50:34 +0100 Message-ID: Subject: Re: [RFC][PATCH 3/N] lto-plugin: Port to C++ To: =?UTF-8?Q?Martin_Li=C5=A1ka?= Cc: GCC Patches , Jan Hubicka Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2022 07:50:47 -0000 On Wed, Jan 5, 2022 at 2:28 PM Martin Li=C5=A1ka wrote: > > Hello. > > I'm working on some changes that will be needed for support of ld.mold. > And I would like to have the plugin in C++. Having that, we can utilize b= asic > contains like std::vector (instead of xrealloc(foo, len + 1)...). > > I split the patch into 2 pieces where the second one is only result > of autoreconf and automake. > > Lightly tested with ld.bfd, ld.gold and lto.exp. With the linker plugin build by GCC using its libstdc++ statically(?) and for example gold (also a C++ application) built by another (GCC) system compiler there might be two different versioned libstdc++ in the process image after dlopening the plugin. Is the libstdc++ "copy" in the plugin sufficiently isolated to not cause problems here? Do we need to pay extra care as to the subset of the C++ standard library we can use (I'm thinking of parts initialized on load time like I/O)? That said, I'm not sure this is worth the trouble. Richard. > > Thoughts? > Thanks, > Martin