From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) by sourceware.org (Postfix) with ESMTPS id ACAD03891C36 for ; Mon, 10 Jan 2022 08:03:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org ACAD03891C36 Received: by mail-ua1-x935.google.com with SMTP id v12so21907511uar.7 for ; Mon, 10 Jan 2022 00:03:14 -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=vVuxbTaCEb/De2f/3ow4ffXiVBmwZaZb19K4w2IWFI4=; b=p+NyGS2Rc7bMUZMA7Wa3FdxxuF217m969ZqsxuU3aNm6l6iTDg3Q+gkayto6pzkYls am6vAQa9dkJGKM4DxRH/QKsyyGzqgmSj5YWlcLM8379SDDHbTTI2iHv5LAf95ob92vxy Hhw6VaqbBMYKZU4b3kCLIcTY7QMDisU7Fsonxl1bxsZjwegm/WRt6KFErKH85YJ8xun7 8gUbOlggmYSQZ1dhyU2cbmt9xWr47VPosZ/u6KuWXtnA+TqDeyqdNw5Neg06Gfs92frB XD8UmXvTado61EN0j4JmOQikzLB96GcKK+yf4zZVJiGus6kx0/YG068AMZcpmPuuSWR/ vhYg== X-Gm-Message-State: AOAM531IXC2cftzL0rxzq7V9seHQVPfbjxewWxtZP+IPvJwAEiIMjc7y iU8KTCDZP4EH+eVNOJdo0b1Of9wqDKmqaOyzofs= X-Google-Smtp-Source: ABdhPJy0Ow54TaOUDJzVgg/GqxV1dtJuRZVoYIBglG6RoGKkSlR4P3waH4qdt4kmpWANQLNQD3kGzCwEF8ffP1zMda8= X-Received: by 2002:a05:6102:a50:: with SMTP id i16mr23964444vss.29.1641801794141; Mon, 10 Jan 2022 00:03:14 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andrew Pinski Date: Mon, 10 Jan 2022 00:03:02 -0800 Message-ID: Subject: Re: [RFC][PATCH 3/N] lto-plugin: Port to C++ To: Richard Biener Cc: =?UTF-8?Q?Martin_Li=C5=A1ka?= , GCC Patches , Jan Hubicka Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 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 08:03:15 -0000 On Sun, Jan 9, 2022 at 11:51 PM Richard Biener via Gcc-patches wrote: > > 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= basic > > 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)? It should be isolated after r12-3491-g9e58de3ce00fc2385 . One of the reasons why I did that patch is because I noticed the lto plugin was exporting some libiberty symbols even. Though I don't know the interaction between that and GNU_UNIQUE symbols which could cause issues. Someone would need to check the symbols on the plugin after this patch to make sure no symbols have either GNU_UNIQUE on them or exported. Thanks, Andrew Pinski > > That said, I'm not sure this is worth the trouble. > > Richard. > > > > > Thoughts? > > Thanks, > > Martin