https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116887
--- Comment #14 from chenglulu <chenglulu at loongson dot cn> --- (In reply to Xi Ruoyao from comment #13) > (In reply to Florian Weimer from comment #11) > > I'm surprised that you can load from .data.rel.ro using la.local. Isn't it > > possible for RELRO data (which is writable at first, so separate from code) > > very far away from any text section? I'm going by the name “la.local” only > > here, I don't know anything about the architecture. I associate “local” > > with “sort, limited displacement”. 8-) > > We are loading the address of something in .data.rel.ro using la.local, then > using that address to load the actual data. And as I've said in the > previous comment it seems just reinventing a GOT entry... > > global/local basically means preemptible or not, i.e. la.global = la.got, > la.local = la.pcrel (unless overriding it with something like > -Wa,-mla-global-with-pcrel which was used by things like the kernel before > GCC have -mdirect-extern-access). (In reply to Xi Ruoyao from comment #12) > (In reply to chenglulu from comment #10) > > (In reply to Xi Ruoyao from comment #8) > > > (In reply to chenglulu from comment #7) > > > It seems like a previous attempt to fix PR 52999: r186919. But it was > > > then > > > reverted and changed to TARGET_SECTION_TYPE_FLAGS in r188031. > > > > > > So which is better? Maybe we'll need to dig some history from the mail > > > list... > > > > > > Comparison of the two assembly codes： > > 1. Define the hook TARGET_SECTION_TYPE_FLAGS > > la.local $r12,.LC0 > > ldptr.d $r12,$r12,0 > > bne $r13,$r12,.L3 > > ... > > jr $r1 > > .cfi_endproc > > .LFE0: > > .size _dlfo_process_initial, .-_dlfo_process_initial > > .section .data.rel.ro > > .align 3 > > .LC0: > > .dword _rtld_global+2048 > > > > > > 2 Another： > > la.global $r14,_rtld_global > > lu12i.w $r12,4096>>12 # 0x1000 > > add.d $r12,$r14,$r12 > > addi.d $r12,$r12,-2048 > > bne $r13,$r12,.L3 > > Hmm I do think 2 is better. It seems we are just "reinventing" the GOT in 1. > > So OK with your approach if it passes regtest. I agree, I'll test the patch
