ELF Visibility test

[Frank]

Dear Anybody at sourceware.org,

I am running linux on an intel pentium 4 machine.
In order to build "binutils-2.15" I ran the testsuite after doing a
"make" and got a few failures as a result of the visibility-test.

All the "hidden_undef_def"-tests ended with failures.

I simulated the first one, the "HIDDEN_UNDEF DSO_PROTECTED_DEF" test
with a bash-script, carefully setting each and every command line 
argument as the expect-script does.

But the answers I found left me in doubt about the actual error source,
so I finally decided to ask you - the test's authors - about what's 
going wrong.

(I hope that this time I am indeed addressing the author's ;))

This is what I found during compiling / binding the sources main.c,
sh1.c and sh2.c:

All three files compile without any errors (using gcc-3.1.4)
Binding the shared library vnp.so is no problem either.

If I understand the test correctly, after binding the shared library,
mainnp.o is bound against vnp.so.
As a test result, with the macros mentioned above defined, four symbols
should be reported as undefined references:
visibility, visibility_var, visibility_def and visibility_func.

The error message I got instead was:

main.c: undefined reference to 'visibility'
main.c: undefined reference to 'visibility_var'
(the latter one twice, with different .text 0x??? - Adresses)

lt-ld-new: tmpdir/vnp: hidden symbol 'visibility_def' isn't defined.
collect2: ld returned 1 exit status

Grepping the symbols out of the object files as readelf prints them, I
got the following
- to my understanding absolutely correct - results:

mainnp.o:   0  | NOTYPE | GLOBAL | HIDDEN | UND      visibility_func
             0  | NOTYPE | GLOBAL | HIDDEN | UND      visibility_def
             0  | NOTYPE | GLOBAL | DEFAULT | UND      visibility
             0  | NOTYPE | GLOBAL | DEFAULT | UND      visibility_var

sh1np.o    0  | NOTYPE | GLOBAL | HIDDEN | UND      visibility
            0  | NOTYPE | GLOBAL | HIDDEN | UND      visibility_var

sh2np.o    4  | OBJECT  | GLOBAL | DEFAULT | 2      visibility_def
            4  | OBJECT  | GLOBAL | DEFAULT | 2      visibility_var
           10  | FUNC     | GLOBAL | DEFAULT | 1      visibility_func
           10  | FUNC     | GLOBAL | DEFAULT | 1      visibility

And the resulting shared library:

vnp.so      4  | OBJECT | GLOBAL | DEFAULT | 13      visibility_def
            10  | FUNC    | GLOBAL | DEFAULT | 10      visibility_func
             4  | OBJECT | LOCAL   | HIDDEN    | 13      visibility_var
            10  | FUNC    | LOCAL   | HIDDEN    | 10       visibility

At first I was a little surprised to find visibility_var and
visibility() declared LOCAL in the shared library,
but declaring them "protected" in the source file made them GLOBAL in
the shared library again so I guess that ld correctly sets their binding 
to LOCAL in accordance with their HIDDEN visibility.

Binding mainnp.o against vnp.so ends with the errors mentioned above.

Removing the ".hidden" from the visibility_def - declaration in main.c
ended with the same error message, but now it was visibility_func's turn:

lt-ld-new: tmpdir/vnp: hidden symbol 'visibility_func' isn't defined.

Is it possible, that the error reporting procedure in ld has changed,
thus resulting in a different error message and an abort of the linkage 
itself after finding one not-defined symbol ?
Which in turn means, that the if-conditional in elfvsb.exp will have to
be changed in order to pass the test.

Or is it a bug in ld itself ?

Or (worst case) a bug in my understanding of the linkage procedure ?

Yours sincerely, Frank Neumann.