From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38282 invoked by alias); 20 May 2019 08:39:56 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 37560 invoked by uid 89); 20 May 2019 08:39:55 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=transfer X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 20 May 2019 08:39:54 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x4K8dpwf017957; Mon, 20 May 2019 03:39:51 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id x4K8dou8017953; Mon, 20 May 2019 03:39:50 -0500 Date: Mon, 20 May 2019 08:39:00 -0000 From: Segher Boessenkool To: Alan Modra Cc: Umesh Kalappa , Eric Botcazou , gcc@gcc.gnu.org Subject: Re: [PowerPC 64]r12 is not updated to GEP when control transferred from virtual thunk function . Message-ID: <20190520083950.GS31586@gate.crashing.org> References: <3290120.NdSNzDBL4k@polaris> <1938670.JyHVrHFxKJ@polaris> <20190515235233.GN8599@gate.crashing.org> <20190516225242.GE31586@gate.crashing.org> <20190520064954.GM6820@bubble.grove.modra.org> <20190520075533.GR31586@gate.crashing.org> <20190520081852.GN6820@bubble.grove.modra.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190520081852.GN6820@bubble.grove.modra.org> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg00158.txt.bz2 On Mon, May 20, 2019 at 05:48:52PM +0930, Alan Modra wrote: > On Mon, May 20, 2019 at 02:55:33AM -0500, Segher Boessenkool wrote: > > On Mon, May 20, 2019 at 04:19:54PM +0930, Alan Modra wrote: > > > On Thu, May 16, 2019 at 05:52:42PM -0500, Segher Boessenkool wrote: > > > > I wonder if you have found a bug in the compiler after all. Most things > > > > are supposed to work without the linker/loader having to do special > > > > things; e.g. using the global entry point should always work, using the > > > > local entry point is just an optimisation. > > > > > > That isn't true for direct calls. If using the global entry point, > > > the linker must provide stub code to load up r12 with the global entry > > > address and modify the nop after the bl. The linker must also adjust > > > calls using the local entry point; the call instruction (and > > > relocation) specify the function symbol not the function plus local > > > entry offset. > > > > > > So I don't think there is any compiler bug here, just a broken kernel > > > module loader. Incidentally, if thunks are broken then it's very > > > likely local function calls are broken too. > > > > The ABI says > > > > "When a linker causes control to transfer to a global entry point, it > > must insert a glue code sequence that loads r12 with the global > > entry-point address. Code at the global entry point can assume that > > register r12 points to the GEP." > > > > But in the testcase the jump *already* was to the global entry point: > > So? We never add the local entry offset to the call assembly. I guess I read that wrong then -- I read it as "when a linker changes some jump so that it goes to a global entry point". But it means it needs to make a stub for every global entry point that is used? Segher