From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) by sourceware.org (Postfix) with ESMTPS id 50CE63851C2A for ; Wed, 7 Oct 2020 23:13:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 50CE63851C2A Received: by mail-ot1-x342.google.com with SMTP id i12so3883372ota.5 for ; Wed, 07 Oct 2020 16:13:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PzqRVakF04XpSZSsSKCbsBZFhtIM2rAH3Hh0hHaH1/o=; b=t7R69/qnrRwcj7vfgnKNHzWaQ2lOkp2eNb51pGXdXSpJAVs9XYc9mcQMTyT7NSnh+s eMEGVFIou6szcCOBFGJmvVBl7+D25dpwW8Q2qpewSg2Exx44Qq85tkppjxXcLKdPMuT7 UwExpksY0TxL2jZGhcCuM+RIOvgODM/Z6IBwLwsAinEtEEJ30wupMKkboZqZDh9w+Z1s sAx8/CvdJe8RhFckgE+quGguCjuV2fBMEYUpXizSOidScagwvPMabiuXVOqH8qf2lHB2 dQow7xeq4inTkQTu3aH7beiQPapE002lvJfTY3JW8n+Q0cYSpZ+XBGaBwaGq9PbVMWXo HGMg== X-Gm-Message-State: AOAM531YgVAS7hRn7WQF7AqzsOyFQpFyvDN5OiR2+ni5/Cim8mrwSChk 96oBLMKeTLzQnvPrFVE64Gjm4zzJ+aMxbrpm7ls= X-Google-Smtp-Source: ABdhPJyGdbqOtNRY7aCNXMzNglOys/RyOAH+rsCAs4Jv+scpDsYypkAmBLjr840f3CUAN5JqeF5jhQYFBdCPwjvoNtI= X-Received: by 2002:a9d:335:: with SMTP id 50mr3072998otv.90.1602112410662; Wed, 07 Oct 2020 16:13:30 -0700 (PDT) MIME-Version: 1.0 References: <8770b080-9da3-e8e5-80a7-afde36ab3e5e@redhat.com> <20200917190342.GE26561@tucnak> <4c1543a1-5785-4603-350b-e0fbdb3d4fa6@redhat.com> In-Reply-To: From: "H.J. Lu" Date: Wed, 7 Oct 2020 16:12:54 -0700 Message-ID: Subject: Re: Problem with static const objects and LTO To: Jeff Law Cc: Jakub Jelinek , GCC Patches , Joseph Myers Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3031.3 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.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Wed, 07 Oct 2020 23:13:32 -0000 On Wed, Oct 7, 2020 at 3:09 PM Jeff Law via Gcc-patches wrote: > > Adding the testcase... > > On 10/7/20 4:08 PM, Jeff Law wrote: > > On 9/17/20 1:03 PM, Jakub Jelinek wrote: > > [ ... Big snip, starting over ... ] > > > > I may have not explained things too well. So I've put together a small > > example that folks can play with to show the underlying issue. > > > > > > There's a static library libfu.a. In this static library we have a hunk > > of local static data (utf8_sb_map) and two functions. One function puts > > the address utf8_sb_map into a structure (rpl_regcomp), the other > > verifies that the address stored in the structure is the same as the > > address of utf8_sb_map (rpl_regfree). > > > > > > That static library is linked into DSO libdso.so. The DSO sources > > define a single function xregcomp which calls rpl_regcomp, but > > references nothing else from the static library. Since libfu.a was > > linked into the library we actually get a *copy* of rpl_regcomp in the > > DSO. In fact, we get a copy of the entire .o file from libfu.a, which > > matches traditional linkage models where the .o file is an atomic unit > > for linking. > > > > > > The main program calls xregcomp which is defined in the DSO and calls > > rpl_regfree. The main program links against libdso.so and libfu.a. > > Because it links libfu.a, it gets a copy of rpl_regfree, but *only* > > rpl_regfree. That copy of rpl_regfree references a new and distinct > > copy of utf8_sb_map. Naturally the address of utf8_sb_map in the main > > program is different from the one in libdso.so and the test aborts. > > > > > > Without LTO the main program would still reference rpl_regfree, but the > > main program would not have its own copy. rpl_regfree and rpl_regcomp > > would both be satisfied by the DSO (which remember has a complete copy > > of the .o file from libfu.a). Thus there would be only one utf8_sb_map > > as well and naturally the program will exit normally. > > > > > > So I've got a bunch of thoughts here, but will defer sharing them > > immediately so as not to unduly influence anyone. > > > > > > I don't have a sense of how pervasive this issue is. I know it affects > > man-db, but there could well be others. This is: https://sourceware.org/bugzilla/show_bug.cgi?id=26530 https://sourceware.org/bugzilla/show_bug.cgi?id=26314 -- H.J.