ld tests about protected visibility

[CHIGOT, CLEMENT]

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

I didn't want to add too much details in order to be as concise as possible.
I said that I was speaking about the test called "protected". But it wasn't
that obvious actually.
Anyway, I should have explained a bit more sorry.

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

As I said, I was following the test named "protected" so vp.so is simply
sh1.c with -DPROTECTED -DSHARED.
Thus, shared_data is defined in the shared lib.  But once again, I should
have mentioned it.

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

Ok, I understand a bit more. I just find it really weird that the test has
the same result whether or not ".protected" is there. Because, that means
that if protected for whatever reasons stops working and is kind of ignored
by the linker, it won't be detected right ?

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

So if I understand correctly, if ".protected" is removed from our testcase and
vp.so is still exporting shared_data, thus, linking with vp.so before mainnp.o
would mean that the data_shared referenced in mainnp.o would be the one
within the shared lib and not the one from the main (because vp.so is
included before mainnp.o) ? While with ".protected" whatever the order is,
"data_shared" references in mainnp.o would always target the one defined
in mainnp.o ?



Thanks,
Clément