Copy relocation vs protected data symbol

[H.J. Lu]

As discussed in

https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00044.html

Protected data symbol defined in shared library can't be updated
from executables, which aren't compiled with PIC, on targets
which require copy relocation to access data defined in shared
library. How should this be addressed in gABI?

--
H.J.

[Alan Modra]

I don't believe it is a gABI issue, nor should it be seen as a problem
with protected symbols. I prefer to see this as a toolchain
implementation issue. Specifically, the old hack used by linkers to
avoid text relocations in a non-PIC executable when accessing
variables defined in a shared library doesn't always work with
protected variables.

--
Alan Modra
Australia Development Lab, IBM

[H.J. Lu]

To make it clear, protected data symbols defined in shared library
can never be accessed from normal executables on x86-64 since
R_X86_64_PC32 relocation is used to reach externally defined
symbols in small and medium models and it will overflow at run-time.
On x86-64, R_X86_64_COPY relocation is required to access externally
defined data symbols in normal executables unless small and medium
models are removed from x86-64 psABI. For x86-64, protected data
symbols are impossible.

--
H.J.

[H.J. Lu]

Another thing is the difference in program behavior between protected
read-write data symbol and normal read-write data symbol is very
small. Its contents can be changed at any time, even before program
enters main ().

--
H.J.

[Cary Coutant]

>>>> Protected data symbol defined in shared library can't be updated
>>>> from executables, which aren't compiled with PIC, on targets
>>>> which require copy relocation to access data defined in shared
>>>> library. How should this be addressed in gABI?
>>>
>>> I don't believe it is a gABI issue, nor should it be seen as a problem
>>> with protected symbols. I prefer to see this as a toolchain
>>> implementation issue. Specifically, the old hack used by linkers to
>>> avoid text relocations in a non-PIC executable when accessing
>>> variables defined in a shared library doesn't always work with
>>> protected variables.

I agree with Alan that it's not a gABI issue -- COPY relocations are a
psABI detail.

>> To make it clear, protected data symbols defined in shared library
>> can never be accessed from normal executables on x86-64 since
>> R_X86_64_PC32 relocation is used to reach externally defined
>> symbols in small and medium models and it will overflow at run-time.
>> On x86-64, R_X86_64_COPY relocation is required to access externally
>> defined data symbols in normal executables unless small and medium
>> models are removed from x86-64 psABI. For x86-64, protected data
>> symbols are impossible.

I understand that you can't use text relocations on the default code
sequence in small and medium models, but that's not the problem --
text relocations aren't the only alternative to COPY relocations.

The main executable can access a protected data symbol in a shared
library simply by using an indirect load. You can do this either by
arranging to use a PIC-like sequence, or simply by initializing a
pointer to the address of the data. On some platforms (e.g., PA-RISC
and Itanium), the PIC-like sequence is standard (and the linker
usually tries to optimize it when it finds the symbol can be resolved
within the module. On others, you may need some compiler support like
__attribute__((dllimport)) to tell the compiler to use the right code
sequence. It's up to the psABI to define how to make it work, but it's
not impossible.

> Another thing is the difference in program behavior between protected
> read-write data symbol and normal read-write data symbol is very
> small. Its contents can be changed at any time, even before program
> enters main ().

Sorry, I don't understand what your point is here. Protected vs.
normal visibility has nothing to do with whether or when you can
change the memory -- only whether the symbol can be pre-empted.

-cary