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

[Alexandre Oliva <oliva@adacore.com>]

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

>     __attribute__((visibility("protected"))) void protected_fun() {}
>     void *get_protected_fun() { return protected_fun; }

> links fine in the non-FDPIC mode but not in the FDPIC mode:

>     R_SH_GOTOFFFUNCDESC relocation against external symbol "protected_fun"

This appears to be in line with the comment over SYMBOL_FUNCDESC_LOCAL:

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


But I'd also consider the possibility that it is wrong for the compiler
to expect a GOTOFF-accessible FD, when the FD is only expected to be
created at run time by the DL.

A protected symbol is visible by name outside its loadable object, so
other objects may refer to it and get a dynamic linker-created function
descriptor that needs to be the canonical one for that symbol.  Which
implies that the relocation to the function descriptor cannot be at a
link-time constant GOT offset.

OTOH, it might seem to make sense to create a local noncanonical FD for
the locally-bound function, to be used only to call the function rather
than as the function address, like a non-canonical PLT entry, but then,
if it's only for local calls, we don't need a FD for calls, we could
just call the function directly.


But the quoted C testcase above makes it clear that what is expected is
indeed the canonical function descriptor, so I think this patch is
papering over a bug in the compiler, that should be generating code to
load the canonical FD address from the GOT rather than assuming the
canonical FD is local to the module just because the symbol binds
locally.


Am I making any sense?

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