From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) by sourceware.org (Postfix) with ESMTPS id 77C063858D28 for ; Fri, 12 Aug 2022 20:44:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 77C063858D28 Received: by mail-ot1-x334.google.com with SMTP id x1-20020a056830278100b00636774b0e54so1308448otu.4 for ; Fri, 12 Aug 2022 13:44:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=a2qaXZcinFJ6g0oJl1yhfqAHyxhE6PA/lgz4HFzJezA=; b=pYp5v5TN2+rRYPAAdtrpbz68m2dPDlkzs8T3TJQ70ahKjZJTvtxT8Yn7I0OaCiiuDM kxY6qbFtnX5FfDJZPBD+S7KQHzkeIIgtCifyMGk0QzWEyKbA30k7Xi5IEjRMztbkeWrl TdYUtUCB2vDg364FwnSSes3FVda+VOO/F6GaFQSiLl6WfSQS5f3bW8yQnBEldQfv0mFu pKdH7yoFEFv8VjNDhBk0DHF0HzsAql4zhrmA70tJFG+wek0YnHUMF6C6DZIhFjzJtAwB qmy3vEdhP9ftnk9qIZ0z/zCVHflPew78y25rYW9nYQIAgFmNT8HiG7DfzYJe+KEuzLR2 t/pA== X-Gm-Message-State: ACgBeo0uRQxwl5+zn0VWjp634KJWFlapckEnv3yXIaBGcU9kIAo/R0pu 8A1yIRsT3AWUV4OgTXLv/H/pAi2wthkEPo2Icag= X-Google-Smtp-Source: AA6agR7Am/Fl6whreuCq/cqxJMrVpeW20nEKS55PaVc8Ma6zZpGAvx29GV3QoKa+e3qg08Ae5Y5EgdesaQTC8BHXp9o= X-Received: by 2002:a05:6830:d8b:b0:616:97ed:18e5 with SMTP id bv11-20020a0568300d8b00b0061697ed18e5mr2188401otb.42.1660337052799; Fri, 12 Aug 2022 13:44:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: YumeYao Date: Sat, 13 Aug 2022 04:44:01 +0800 Message-ID: Subject: Re: libstdc++ ABI update rule? (baseline_symbols.txt) To: Jonathan Wakely Cc: "libstdc++" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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: Fri, 12 Aug 2022 20:44:15 -0000 On Wed, Aug 10, 2022 at 9:56 PM Jonathan Wakely wrote: > > > > On Tue, 9 Aug 2022, 17:10 YumeYao via Libstdc++, wrote: >> >> Hi All, >> >> I'm trying to do some experimental optimization to libstdc++, which >> involves heavy use of __builtin_constant_p(), this, however, >> eventually impacts how gcc calculate inlining or not, hence I got >> error when testing libstdc++ about ABI changes. > > > > What errors do you get? added symbols / incompatible symbols. For example I got some std::basic_string<_Char>::function instantiations, because I touched string headers. >> >> Specifically, I met most of such issues when optimizing basic_string. >> >> Then I tried fix the ABI changes by templatizing the functions, > > > That certainly isn't going to work, that's explicitly introducing an ABI change which seems a strange way to try to fix ABI breakage. Actually it did work. I introduced some helper functions in std::basic_string, and somehow some of them didn't get inlined and appeared in the ABI check as added symbols as a result of template class member function instantiation. I then changed the helper function into a (template class member) template function and it didn't appear in the ABI check any more. >> adding >> __attribute__((always_inline)) and even gnu_inline(sometimes adding >> only always_inline breaks the optimization, I noticed this issue very >> long ago...) to the failed parts, which in turn makes other existing >> functions in libstdc++ got uninlined and present in libstdc++.so as >> ABI changes of added symbols/functions. >> >> What really confuses me is the following fact: >> >> without any attribute notation and only by templatizing functions, I >> managed to get a version working on some old gcc version without any >> abi change. > > > > I don't understand how. > I don't understand either. Initially on gcc7 I didn't use template class member template function, then ABI check complained about added symbols. Then like I said above, I turned them into template class member template functions and got ABI fixed. Then I migrated the code change to gcc8, only getting the issue again. So I manually fixed the ABI break by always_inline'ing the functions corresponding to the added symbols. Initially it resulted the outer (caller) functions got un-inlined, resulting in the outer functions appearing as added symbols in ABI check, so I had to add always_inline level by level until I met a caller function that was in the existing ABI list already. > >> But it then failed when I migrated it to a newer version. >> >> I have some basic knowledge about extern template and inlining and >> symbols, etc. and I tried to find the answers from gcc source, but >> obviously there's something beyond the source. >> >> I know inline decision is calculated by pseudo "cost", therefore not >> only the change in library could make an ABI change, but also the >> logic change in gcc inline calculator could make such change, even >> more, how the user uses the code can also make a difference on inline >> decision because the times or frequency of using a library function >> can also impact the inline decision. >> >> So I want to ask: >> >> 1. how the ABI of libstdc++ is maintained in gcc, just update >> baseline_symbols.txt unconditionally when preparing for a release? >> >> 2. How does gcc decide to put which symbol to libstdc++.so? I can see >> files named xxxx-inst(antiation).cc but obviously some symbols not >> belonging to it get instantiated and put in libstdc++.so > > > See https://gcc.gnu.org/onlinedocs/libstdc++/manual/appendix_porting.html#build_hacking.configure.version > > This seems to only explain ABI versioning, which is something I'm already (somewhat) aware of. But here in question 2 I didn't mean gcc community, I actually meant the compiler itself. Well, to me, the Makefiles in gcc are just some dinosaurs I don't want to read over. So... just let me guess. I guess it's when compiling some source files in libstdc++ the default visibility is on for that compile unit (for exporting symbols). So when some functions don't get inlined while compiling such files, these functions appear in libstdc++.so as added symbols. Fix me if it totally doesn't work in this way...