https://sourceware.org/bugzilla/show_bug.cgi?id=32591
--- Comment #16 from Jan Beulich <jbeulich at suse dot com> --- (In reply to H.J. Lu from comment #15) > (In reply to Jan Beulich from comment #14) > > (In reply to H.J. Lu from comment #13) > > > I created a testcase which generates a linker error > > > > > > failed to convert GOTPCREL relocation against '__stack_chk_guard'; relink > > > with --no-relax > > > > > > similar to > > > > > > https://lists.xenproject.org/archives/html/xen-devel/2024-12/msg00630.html > > > > > > based on the xen linker script, xen/arch/x86/xen.lds. My patch works. > > > > It doesn't on full Xen. As expected I see > > > > ASSERT(!SIZEOF(.got), ".got non-empty") > > GOT is used to access local symbol beyond 4GB. Xen can disallow run-time > relocations in GOT. But GOT won't be empty. Xen needs to deal with it if > it wants to access the local stack protector symbol. Why? Xen compiles all of its code with -fpic. The check is there to verify that the compiler doesn't needlessly emit inefficient code (going through GOT in this case; we have more of such checks there). There are technical reasons why we can't pass -shared or -pie to the linker, and hence why - with how things currently work - the MOV->LEA transformation won't be engaged. Yet that's what is needed to yield an empty GOT again, compensating for the compiler needlessly emitting accesses through GOT for accesses to __stack_chk_guard (gcc bug 118473). But yes, this is the less severe part of this bug report - it's more "missed optimization" than "failing to link". > > triggering. I wonder whether you actually copied that when deriving the > > linker script from Xen's. > > I used section layout in Xen's linker script to have local symbol beyond > 4GB. The question here isn't "beyond 4Gb" but "within 2Gb reach for PC-relative accesses". -- You are receiving this mail because: You are on the CC list for the bug.
