From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100119 invoked by alias); 15 May 2018 20:49:44 -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 99651 invoked by uid 89); 15 May 2018 20:49:20 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Removal, HTo:U*fw X-HELO: mx0a-001b2d01.pphosted.com From: Tulio Magno Quites Machado Filho To: Florian Weimer , Rogerio Alves Cc: libc-alpha@sourceware.org Cc: Subject: Re: [RFC] powerpc: restore TOC when static longjmp to shared object In-Reply-To: <87tvr8u50v.fsf@mid.deneb.enyo.de> References: <5e8159c9-f6d2-9429-479b-fe436a7f2a88@linux.vnet.ibm.com> <87tvr8u50v.fsf@mid.deneb.enyo.de> User-Agent: Notmuch/0.25 (http://notmuchmail.org) Emacs/25.3.1 (x86_64-redhat-linux-gnu) Date: Tue, 15 May 2018 20:49:00 -0000 MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 x-cbid: 18051520-0012-0000-0000-0000163E2C74 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00009030; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000260; SDB=6.01032809; UDB=6.00528039; IPR=6.00811940; MB=3.00021133; MTD=3.00000008; XFM=3.00000015; UTC=2018-05-15 20:48:58 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18051520-0013-0000-0000-000052C76D6D Message-Id: <87po1wir0o.fsf@linux.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-05-15_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=8 spamscore=0 clxscore=1015 lowpriorityscore=8 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1805150202 X-SW-Source: 2018-05/txt/msg00598.txt.bz2 Florian Weimer writes: > * Rogerio Alves: > >> One simple solution would be always restore the TOC pointer by uncomment >> the line bellow: >> >> /* std r2,FRAME_TOC_SAVE(r1) Restore the TOC save area. */ >> >> Or maybe we can check if we have a valid TOC pointer before restore it, >> instead #if defined SHARED. > > Is the register reserved for the TOC pointer in static builds, too? > Then I suggest to unconditionally save nad restore it; not doing so > looks like a pointless micro-optimization. > > Another problem with sharing jump buffers across static dlopen is that > you might not have identical pointer guard values. > >> I would like to request for comments on this matter: Should we fix/work >> this? Is feasible to change longjmp to always restore TOC pointer? > > Does setjmp already save it unonditionally? > > Removal of static dlopen is still some time away; it's likely not > going to happen in this cycle, and the fix looks simple enough. If static dlopen is still going to be supported for some cycles, I also agree it should be saved and restored unconditionally. -- Tulio Magno