[PATCH v2] sh: Make protected symbols local for FDPIC -shared

[Alexandre Oliva]

On Mar  7, 2024, Fangrui Song <maskray@google.com> wrote:

>>> /* Decide whether a reference to a symbol can be resolved locally or
>>> not.  If the symbol is protected, we want the local address, but
>>> its function descriptor must be assigned by the dynamic linker.  */
>> 
>> If the comment is wrong as your proposed change suggests, it ought to be
>> fixed along with the patch that changes this behavior.

> The comment looks correct to me, so I did not update it.

The point was about having the descriptor assigned by the dynamic
linker.  You seem to be arguing against it to enable GOTOFF references
to the descriptor.  You can only use GOTOFF for descriptors that are
local to the module, I hope you'll agree.

I understand the motivations for performance, but ISTM that twisting the
meaning of protected to satisfy those motivations is not a desirable
path to take; hidden aliases seem to satisfy that goal without deviating
from any standard behaviors.

Now, I'm not aware of any special provisions in SH FDPIC specs that
would justify this change, so I'd rather stick to the overall standard.

> Let's say a.so defines protected `foo`, which is referenced by b.so
> using the default visibility symbol.

That is unclear to me.  Are we talking about two different symbols, each
with different visibility, or about two different views of the same
global symbol?

> The references within a.so use GOTOFF relocations, which are resolved
> to the canonical function descriptor.

That can't be.  The comments in place (quoted above) state that it is
the dynamic linker that assigns the descriptor for the symbol, so you
can't possibly refer to it with GOTOFF, even if the symbol otherwise
binds locally.


Now, one could conceive of using a local descriptor as the canonical
one.  FDPIC has never had provisions for that AFAIK: the dynamic loader
has no visibility into local descriptors or their associations to local
symbols.  IMHO some means to enable that would have to be added before
this kind of change could be considered.

-- 
Alexandre Oliva, happy hacker            https://FSFLA.org/blogs/lxo/
   Free Software Activist                   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive