From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 429 invoked by alias); 23 May 2018 09:27:21 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 390 invoked by uid 89); 23 May 2018 09:27:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: smtp.ispras.ru Date: Wed, 23 May 2018 09:27:00 -0000 From: Alexander Monakov To: Rogerio Alves cc: libc-alpha@sourceware.org Subject: Re: [RFC] powerpc: restore TOC when static longjmp to shared object In-Reply-To: <4c67a306-d447-1158-1b92-22ed1cfcfa0a@linux.vnet.ibm.com> Message-ID: References: <4c67a306-d447-1158-1b92-22ed1cfcfa0a@linux.vnet.ibm.com> User-Agent: Alpine 2.20.13 (LNX 116 2015-12-14) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2018-05/txt/msg00753.txt.bz2 On Tue, 22 May 2018, Rogerio Alves wrote: > I've attached patch v2 to this email with the fixes suggested by Adhemerval. Why was it necessary to change the prototype of lbar(), and does the testcase still demonstrate the issue with that change (does it fail without the patch)? Note that as soon as gcc is capable of optimizing out the alloca-memset code in the testcase, it will no longer serve the purpose (maybe it's already capable, when preparing the testcase I only checked -O0 IIRC). Surely there are more direct and robust ways of checking that TOC is correctly restored? Alexander