ld tests about protected visibility

[Michael Matz]

On Thu, 25 Nov 2021, CHIGOT, CLEMENT via Binutils wrote:

> Hi everyone, 
> 
> I'm currently implementing visibility for XCOFF format and while doing 
> so I'm running tests inside "ld-elfvsb" testsuite. 

As you probably noticed those tests test many different things with the
same sources, depending on how they are compiled.  So, that makes it all a 
bit non-obvious.  In particular you aren't providing enough information to 
know ...

> With ".protected" in main.c, 

... how main.c ...

> $ readelf -s tmpdir/mainnp.o | grep shared_
>     42: 0000000000000000     4 OBJECT  GLOBAL PROTECTED    2 shared_data
>     43: 0000000000000020    10 FUNC    GLOBAL PROTECTED    1 shared_func
> $ gcc ... -o tmpdir/vp ... tmpdir/mainnp.o tmpdir/vp.so

... and especially how vp.so was compiled for the cases you are interested 
in.  The protected tests about shared_func and shared_data are testing the 
following scenarios (I'll only state shared_data, shared_func is similar, 
except it can also be called):

(a) protected shared_data in executable, _no_ shared_data in shared lib
(b) protected shared_data in executable, global shared_data in shared lib

(In particular, the shared_data in executable is always protected in these 
tests, so your experiment (removing protected in main.c) is not one of the 
tests).  In both cases all references to shared_data should resolve to the 
one in the executable.  That is tested, and the return code is 0 if that 
works as expected.  In your cases it does work as expected, the definition 
in the executable prevails.

If you remove .protected from main.c then the shared_data in executable 
will be global and trivially be the one that everything is resolved to 
(because in ELF the executable is first in all symbol lookups).  It's only 
when the symbol in the exe is protected that something interesting happens 
(namely one could be of the opinion that the definition of shared_data in 
the shared lib in case (b) should prevail, but that is explicitely not so, 
which is what's tested).

> As I'm not fully aware of all the subtleties of ELF and visibility, does 
> anyone know if this is intended and if it's not what it should be ?

So, yes, removing .protected from main.c should have the effect you see; 
but as said, it's not an interesting test as no protected visibility would 
be involved anymore, just normal default ELF lookup rules.

In case it helps: protected symbols are conceptually fairly simple: a 
protected symbol in component (exe or shared lib) A is visible from other 
components B (i.e. it's exported).  References to that symbol from within 
component A are resolved to the symbol in component A, no matter if other 
components also define that symbol (this is in difference to normal ELF 
lookup rules, which state that the first symbol found in a global breadth 
first search of all components is the one that all references resolve to).


Ciao,
Michael.