From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14831 invoked by alias); 15 May 2019 17:47:58 -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 14642 invoked by uid 89); 15 May 2019 17:47:58 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.1 spammy=HTo:U*ebotcazou, or, HX-Received:a510, H*i:sk:3290120 X-HELO: mail-pl1-f175.google.com Received: from mail-pl1-f175.google.com (HELO mail-pl1-f175.google.com) (209.85.214.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 15 May 2019 17:47:57 +0000 Received: by mail-pl1-f175.google.com with SMTP id n8so212427plp.10 for ; Wed, 15 May 2019 10:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1ExB23ugRXTqcOlxgOY/EgQiKE9Gf5qtx5AEC8i5R4U=; b=pUZu9FoAU+NjQY1Qj19VGaQfACnmrdgLxYJoAMJItYmustu00j8xQVgd3BT+i0pyyM 6epGG0TmpEadAub6mU5ZzI5l/8ZrNTjtDimhgqgE/HiOf1YbZJclncWmr5WdRFT1YaKP 9A9t8vB3u2i/gRVnt+fw9ljceh3Aoa0AeKjKLLatCmM7LLT4c8FcFQ4IapBd4F0AUTXV fR0sZcpcJkVToc0BnHWgLfoqbIqseWAe4AS6RDKuUPDynWNFkqwYJHKnZBNSvY6SUvdv /701TtWkHjtJZgC3lhIOAJAJXRJ9EcI+A6bu7kg3zwNli97rqbyrlIZUDT0Z/SbxaKS1 cZCw== MIME-Version: 1.0 References: <3290120.NdSNzDBL4k@polaris> In-Reply-To: <3290120.NdSNzDBL4k@polaris> From: Umesh Kalappa Date: Wed, 15 May 2019 17:47:00 -0000 Message-ID: Subject: Re: [PowerPC 64]r12 is not updated to GEP when control transferred from virtual thunk function . To: Eric Botcazou Cc: gcc@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg00120.txt.bz2 Thank you Eric for the suggestion and say that we support in the loader part ,can you please point on elfv2 reference that says implementation for this specific case. ~Umesh On Wed, May 15, 2019, 21:35 Eric Botcazou wrote: > > like above the control from "_ZThn8_N12Intermediate1vEv" (support > > function for this pointer update) is transferred > > "_ZN12Intermediate1vEv" by b inst (where its not updating the r12) > > and in the beginning of "_ZN12Intermediate1vEv" we are loading the > > toc base from r12 (which is incorrect ) ,we are investigating the > > issue and one way to fix the issue is that make THUNK to update the > > r12 ,the cal like bctrl or load the r12 with the function address in > > the _ZN12Intermediate1vEv prologue code . > > Is that on VxWorks in kernel mode? If so, the loader doesn't abide by the > ELFv2 ABI so the simple way out is to disable asm thunks altogether: > > #undef TARGET_ASM_CAN_OUTPUT_MI_THUNK > #define TARGET_ASM_CAN_OUTPUT_MI_THUNK rs6000_can_output_mi_thunk > > /* Return true if rs6000_output_mi_thunk would be able to output the > assembler code for the thunk function specified by the arguments > it is passed, and false otherwise. */ > > static bool > rs6000_can_output_mi_thunk (const_tree, HOST_WIDE_INT, HOST_WIDE_INT, > const_tree) > { > /* The only possible issue is for VxWorks in kernel mode. */ > if (!TARGET_VXWORKS || TARGET_VXWORKS_RTP) > return true; > > /* The loader neither creates the glue code sequence that loads r12 nor > uses > the local entry point for the sibcall's target in the ELFv2 ABI. */ > return DEFAULT_ABI != ABI_ELFv2; > } > > -- > Eric Botcazou >