On Tue, Jan 07, 2020 at 07:10:34PM +0100, Ard Biesheuvel wrote: > On Tue, 7 Jan 2020 at 19:08, Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote: > > > > On Tue, Jan 07, 2020 at 06:59:57PM +0100, Ard Biesheuvel wrote: > > > On Tue, 7 Jan 2020 at 18:58, Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote: > > > > > > > > On Tue, Jan 07, 2020 at 03:28:31PM +0100, Ard Biesheuvel wrote: > > > > > > > > > > Unfortunately, the command line option implements a weaker form of > > > > > visibility than the pragma, so it probably comes down to setting the > > > > > pragma in a .h file that gets -include'd via the command line so it is > > > > > guaranteed to be seen first. > > > > > > > > Tried hacking that in and it works, tested with gcc 4.6.4. > > > > > > Excellent. But in my testing locally, I don't get any GOT entries in > > > the first place, strangely enough. So what changes in the output for > > > you with visibility hidden compared to before? > > > > Works with 32-bit as well. > > > > Are you checking libstub or boot/compressed? Below is with gcc 4.6 (but > > latest binutils). With gcc 9, there's only one left -- trampoline_32bit_src > > in pgtable_64. > > > > I am looking at the size of the .got section in > boot/compressed/vmlinux, and it is 0x0 on 64-bit, and 0xc (i.e., only > the .got.plt fixup code) on 32-bit. > > Could you please check whether passing -Bsymbolic to the linker gives > the same result btw? > With new ld all those GOTPCRELX's get eliminated. If you add --no-relax you'll get them in the .got. I don't have an old version of binutils so I can't check, but I think they will be assembled as GOTPCREL and remain in the .got section after linking. A linker option can't help I'd think, because once these relocations are there in the object files, you need the new binutils to get rid of them. I didn't get any difference with -Bsymbolic -- also that seems to be for shared libraries, with executables the references should already be bound within the executable, shared libraries can't override them.
