Hi, on 2019/5/16 上午7:37, Segher Boessenkool wrote: > Hi Umesh, > > Please spell out "global entry point", almost everything and everyone does. > > On Wed, May 15, 2019 at 08:57:29PM +0530, Umesh Kalappa wrote: > >> .set .LTHUNK0,_ZN12Intermediate1vEv > >> _ZThn8_N12Intermediate1vEv: >> .LCF2: >> 0: addis 2,12,.TOC.-.LCF2@ha >> addi 2,2,.TOC.-.LCF2@l >> .localentry >> _ZThn8_N12Intermediate1vEv,.-_ZThn8_N12Intermediate1vEv >> b .LTHUNK0 > >> _ZN12Intermediate1vEv: >> .LCF1: >> 0: addis 2,12,.TOC.-.LCF1@ha >> addi 2,2,.TOC.-.LCF1@l > >> 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 . > > The thunk should point to the local entry point instead, I guess? >
I do think so. The call is locally, linker should know it's local and fix it up with local entry instead. We don't need to keep r12 always hold the entry of being called function. > Please open a PR, with compilable testcase, and other relevant info (if > you need some specific -mcpu= for example, or other flags, do mention > that!) See https://gcc.gnu.org/bugs.html for more info. Thanks! > > > Segher >
