From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57763 invoked by alias); 15 May 2018 19:15:40 -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 57568 invoked by uid 89); 15 May 2018 19:15:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=Removal, HTo:U*fw, reserved X-HELO: mx0a-001b2d01.pphosted.com Subject: Re: [RFC] powerpc: restore TOC when static longjmp to shared object To: Florian Weimer Cc: libc-alpha@sourceware.org References: <5e8159c9-f6d2-9429-479b-fe436a7f2a88@linux.vnet.ibm.com> <87tvr8u50v.fsf@mid.deneb.enyo.de> From: Rogerio Alves Date: Tue, 15 May 2018 19:15:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <87tvr8u50v.fsf@mid.deneb.enyo.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 18051519-0044-0000-0000-00000414C1CE 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.01032777; UDB=6.00528021; IPR=6.00811909; MB=3.00021130; MTD=3.00000008; XFM=3.00000015; UTC=2018-05-15 19:15:15 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18051519-0045-0000-0000-00000846D665 Message-Id: <068d9ed5-ace4-c799-383e-bed4025a8d00@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-05-15_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1805150188 X-SW-Source: 2018-05/txt/msg00593.txt.bz2 Em 15-05-2018 15:50, Florian Weimer escreveu: > * 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. > Yes. And, I agree with you: it's kinda 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? Yes it saves. But the only difference it retrieves from the caller when shared: #if defined SHARED && !IS_IN (rtld) ld r5,FRAME_TOC_SAVE(r1) /* Retrieve the callers TOC. */ std r5,(JB_GPR2*8)(3) #else std r2,(JB_GPR2*8)(3) > > 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. > Yes. In fact I am already working on a patch here just in case. Thank you Regards