From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 438DC3858D37 for ; Tue, 23 Aug 2022 14:34:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 438DC3858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 27NEXBK6032654; Tue, 23 Aug 2022 09:33:11 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 27NEXApt032653; Tue, 23 Aug 2022 09:33:10 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Tue, 23 Aug 2022 09:33:10 -0500 From: Segher Boessenkool To: "Kewen.Lin" Cc: GCC Patches , David Edelsohn , AlanM Subject: Re: [PATCH v3] rs6000: Rework ELFv2 support for -fpatchable-function-entry* [PR99888] Message-ID: <20220823143310.GV25951@gate.crashing.org> References: <20220818173435.GN25951@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Tue, 23 Aug 2022 14:34:13 -0000 On Fri, Aug 19, 2022 at 10:40:10AM +0800, Kewen.Lin wrote: > Since you proposed to update the documentation, I'm thinking if we can > reconsider Fangrui's proposal in the PR which Alan seconded: Put preceding > nops before GEP and succeeding nops after LEP. Previously I had the concern > that the nops inserted doesn't respect to a same function entry, it looks > inconsistent to the documentation, and you also noted that "The nops have > to be consecutive". If we want to update the documentation, could we reword > it for PowerPC ELFv2 ABI? > > What's your opinion? I'm not sure what the question is, sorry. If you want different semantics for ELFv2 (which might well be useful), we need some new command line option for that. I suggested here to just describe in the existing doc what is done for global and local entry points on ELFv2. Segher