On Tue, 7 Jan 2020 at 19:32, Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote: > > 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. > Right, unless you use hidden visibility, no? > 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. PIE and .so support share a *lot* of code in binutils. In the arm64 kernel, we use Bsymbolic to get rid of a few absolute symbol references, even though the -pie linker option should take care of that, but it doesn't in all cases.
