https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886
--- Comment #29 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Thiago Macieira from comment #27)
> Still, if this were solved properly, relocations that resolved back into the
> executable itself would still be bound locally, even position-dependently if
> that's how the binary were built. I am asking that it stop doing copy
> relocations, which only applies to symbols the linker *did* detect came from
> elsewhere.
You are missing the point of copy relocations. Consider:
int a = 1;
extern int b, c;
int foo (void)
{
return a + b + c;
}
compiled with -fno-pic or -fpie. a is known to be defined in the executable,
but b and c are externals. Without copy relocations you'd need to emit
significantly slower code (extra .got reference or similar) for all the
accesses to the externals, with copy relocations you can optimistically assume
they will likely be defined in the executable (usual case for larger programs,
at least for C shared libraries people avoid exporting variables from shared
libraries if easily possible), and if not, the linker will create copy
relocations.
Only with whole program (LTO or similar) compilation, when you can talk to the
linker, you could find out if the externals from some TU are defined within the
executable or not.
