From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) by sourceware.org (Postfix) with ESMTPS id 036BE385843A for ; Wed, 10 Aug 2022 13:56:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 036BE385843A Received: by mail-ed1-x52f.google.com with SMTP id x21so19193114edd.3 for ; Wed, 10 Aug 2022 06:56:12 -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=X5OEquPRZCvHOpNDQRdWu/VGfdnNI6QmjtPsOmhkK+I=; b=3CoIB2njMyjM0c46zLtIzjZ6qP1+c4BVETwROx2k1lN2foASwSaJZUmmGRWc9tadTb IjXK9poyg5+9v27hH1GSmGYO4Dos2yTLuz743rdUfzCQjzSUfhPWP0F6HM+qMApSg8Gy Z34T/C4g3IiI/+aJ32H/FexuPBuC01d0wiLldK2zArWb0T2PetJVmzePalw21pW2kdNT 5u+hifDYqTN9VuKH/kVeRLB40se/37xEjJpnKjIOSMPj/Kw9vtvilipuEamYel9IJl8+ MAVmvWkkYaOyXDOa96+WsDyB3Tmj8BYG+2bRJgzoHPce6rLJpQUGaDqSxuib+LWbuXMz zjWw== X-Gm-Message-State: ACgBeo2PD815yMTbNcYjCJ37gdMgHJdqbfjE3IGY4xbZ81N2L68iOTN6 Mfz8Mh/9k82Bc2ZsIuAYhBM7ueocG76NKbCdrM8= X-Google-Smtp-Source: AA6agR43OWznHyGQ91ocn8ZpLdk3u1WDidqc4la5gbJ3UTjjCCXBGm8YrAes2Hw0xMrDd+0zzqB5TB4g/RyLITsIqek= X-Received: by 2002:a05:6402:50cb:b0:440:87d4:3ad2 with SMTP id h11-20020a05640250cb00b0044087d43ad2mr15465776edb.219.1660139771747; Wed, 10 Aug 2022 06:56:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Wed, 10 Aug 2022 15:55:57 +0200 Message-ID: Subject: Re: libstdc++ ABI update rule? (baseline_symbols.txt) To: YumeYao Cc: "libstdc++" X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, 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 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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, 10 Aug 2022 13:56:15 -0000 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? > 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. 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. 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