[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic

["thiago at kde dot org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886

--- Comment #31 from Thiago Macieira <thiago at kde dot org> ---
(In reply to Jakub Jelinek from comment #29)
> 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.

That is true.

But if you place the same code in a library, then now all accesses must be
indirect, even for a. My assertion isn't about the usefulness of copy
relocations, it's that they are optimising for the wrong thing. The size and
complexity of libraries and plugins in desktop applications is orders of
magnitude above that of the application codebases.

> 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.

Or if we tag them appropriately.

int a = 1;
extern int b;
__attribute__((dllimport)) extern int c;
int foo(void)
{
    return a + b + c;
}

Now the compiler knows that a is in the local executable and it can assume that
b is too, but it  also knows that c isn't and must be accessed indirectly. This
did not require LTO.

Modern libraries already all have a macro preceding all the function and
variable declarations meant to be used by other DSOs, ever since Ulrich
Drepper's "dso-howto" manual. The macro tags are required so that we have a
proper __attribute__((visibility("default"))) when the library is compiled with
-fvisibility=hidden. Moreover, the same tag expands to __declspec(dllexport) or
__declspec(dllimport) on Windows if the library is cross-platform. So the
precedent is there and modern libraries are mostly ready to make use of the
feature.