From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) by sourceware.org (Postfix) with ESMTPS id D54023858C27 for ; Wed, 17 Nov 2021 02:16:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D54023858C27 Received: by mail-pg1-x535.google.com with SMTP id 28so813497pgq.8 for ; Tue, 16 Nov 2021 18:16:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=mUrHtaWc9e2/fvj+WrvK+RJ08WR7OP505mlEMxCNlFU=; b=yiEu6caeFJjXgXyDL4AUu9cmF9k+YUbYDhR7mf6GkYVC7ET0XMeeSjLhOD2BhJgJUw W2JyDPNNHW7moClNnhSLe0NZnSeJz0IBXhHRbOQtdCLMGHxchh9pgzn3k2/ZgHdrNiJM OS+iwbS88+WMgYq1kIMrBoMbXSJLpO6aho3VZf9KmCR02rRot1vGt/PuyKcq6VPIjFYj nSviFRxccOpvcjCi33oZ2iAjQWqbx/4WhYqPcw7zYjfdMF4QIKS74+EDbbNo2RrCNdVV TeGesP2M2i9JL2SWfAvL8Tc2Lm2gGi8IFa5DW2PhK/R0AfLeS0tCmRfqjriQaoYZPU1Q tc0A== X-Gm-Message-State: AOAM532oOJj2riZtvZmSHFahx0I16DRBlv+OB3iNRStO9hFsq7dw8X6l u24ZLAQ4ZxczQ6tbULBVjvw= X-Google-Smtp-Source: ABdhPJxmtg0327JkaXacd38d5KXIV0izvwXV0ccgaNDrSTprqTutIY4IRsK1+0/VEFvBxHqgHn0ZrA== X-Received: by 2002:a63:e444:: with SMTP id i4mr2713846pgk.474.1637115372085; Tue, 16 Nov 2021 18:16:12 -0800 (PST) Received: from squeak.grove.modra.org (158.106.96.58.static.exetel.com.au. [58.96.106.158]) by smtp.gmail.com with ESMTPSA id a11sm19743247pfh.108.2021.11.16.18.16.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Nov 2021 18:16:11 -0800 (PST) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id 9C9A111403A9; Wed, 17 Nov 2021 12:46:08 +1030 (ACDT) Date: Wed, 17 Nov 2021 12:46:08 +1030 From: Alan Modra To: Tulio Magno Quites Machado Filho Cc: Adhemerval Zanella , Nemanja Ivanovic , libc-alpha@sourceware.org, Fangrui Song Subject: Re: [PATCH] powerpc: Define USE_PPC64_NOTOC iff compiler and linker also supports it Message-ID: References: <20211108113316.8867-1-adhemerval.zanella@linaro.org> <20211108224808.iqpddl4vgnx2gwol@google.com> <87zgq33n1k.fsf@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zgq33n1k.fsf@linux.ibm.com> X-Spam-Status: No, score=-3032.5 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: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2021 02:16:15 -0000 On Tue, Nov 16, 2021 at 04:42:15PM -0300, Tulio Magno Quites Machado Filho wrote: > Alan Modra via Libc-alpha writes: > > > I have a question about powerpc64/ppc-mcount.S. Why is the assembly > > wrapper using ENTRY and a NOTOC call? By using ENTRY you are saying > > that calls to _mcount must have r2 valid. Given that r2 is valid, why > > then use NOTOC? > > I wouldn't be surprised if that was a misinterpretation of the ABI on my part. > > Looking at table 2.20 "Protocols for Local Function Calls", I think this is a > scenario that falls to the last row of this table, where we have: As Bill said, the ABI does define what is meant by local. However, it is true that if you have enough control over the full build process (you never do when !SHARED in glibc) and know what you're doing, you may use a wider definition of "local". It's something like "I know this function linkage will be exactly the same as a static function in the current compilation unit". Which implies known local definition at link time that cannot be overridden, *and* same toc group. The latter condition is often forgotten, and bites people using ELFv1 -mcmodel=small code when the TOC exceeds 64k. > - Local call method > - nop is not needed > - Relocation is R_PPC64_REL24_NOTOC. > > If this interpretation is incorrect, what is the recommended solution for this > case? Use ENTRY_TOCLESS? If you use ENTRY_TOCLESS you are saying that the function neither uses nor changes r2. This situation is not covered by table 2.19 or 2.20 in the ABI, because ENTRY_TOCLESS functions generally do not make calls! There is a note saying that it is not forbidden but then *you* must ensure that the call does not change r2. Now it might be that __mcount_internal currently does not change r2, but that won't necessarily hold for all future compilers. Power10 pcrel code may use r2 as a scratch register.. I recommend losing the NOTOC on the call. You already have the nop after the call when !SHARED, which is correct and necessary for a normal call. You also likely have enough control over SHARED builds to omit the nop in that case. Note that having a localentry:8 _mcount is not ideal if someone wants to build -mcpu=power10 glibc, but _mcount is quite a way down on the priority list of removing localentry:8 functions for -mcpu=power10. -- Alan Modra Australia Development Lab, IBM