Re: [PATCH] Allow direct access relocations referencing a protected function symbol

[Alan Modra <amodra@gmail.com>]

On Thu, Jun 17, 2021 at 10:25:09AM -0700, H.J. Lu wrote:
> On x86-64, function pointers in executable for external funtions may be
> resolved to their PLT entries in executable.  If it happens, function
> pointers of protected funtions in shared libraries must be resolved to
> the PLT entries in executable, not addresses of protected funtions in
> shared libraries.

Yes, but quite plainly we have a broken toolchain at the moment.  With
correct options for generating shared library code, gcc generates
objects that ld.bfd refuses to link.  That's BAD.  At a minimum the ld
error needs to be reduced to a warning, but preferably silenced.

What's more, function pointer comparisons work in many cases when the
executable is a PIE, even on x86.  For example

library:
void __attribute__ ((visibility ("protected")))
protfun (void) { __builtin_printf ("Address in lib is %lx\n", (long) &protfun); }

executable:
extern void protfun (void);
int main (void)
{
  __builtin_printf ("Address in main is %lx\n", (long) &protfun);
  protfun ();
  return 0;
}

And this variant of the executable

extern void protfun (void);
void *const addr = &protfun;

int main (void)
{
  __builtin_printf ("Address in main is %lx\n", (long) addr);
  protfun ();
  return 0;
}

only fails when PIE due to ld.bfd needlessly emitting a dynamic
protfun symbol with non-zero value.  It's not needed when the const
"addr" is in .data.rel.ro, a writable section when ld.so is
relocating.

-- 
Alan Modra
Australia Development Lab, IBM