--allow-shlib-undefined is a separate issue.  Do you have a run-time testcase
without --allow-shlib-undefined.

For

ld.bfd a.o --as-needed b.so -o bfd.unneeded

since there is no DT_NEEDED tag, no dynamic section is created.

When --as-needed is in action, a shared object is added as a DT_NEEDED tag if it satisfies a non-weak undefined reference from a regular object (surviving under --gc-sections). This is the main use case of the option.

Apparently in GNU ld, --as-needed is also used to decide whether a definition needs to be exported. I think it'd be good if this task can be detached from --as-needed (like gold).

For an "unneeded" (in terms of --as-needed) shared object, it may be loaded by other shared objects.

Adding the shared object on the command line is an explicit intention that the "unneeded" (unneeded by the executable, but
may be needed by other shared objects) may require some definitions to be exported. (The definitions may be statically known (by transitive loading of shared objects; the behavior is related to --copy-dt-needed-entries) or dynamic (dlopen).)

I have a patch.  But I need a run-time test without--allow-shlib-undefined
to justify it.

ld.bfd a.o --as-needed b.so

Let a.o define a function which will be called by b.so via dlopen. In this case, ld should export the function. This justification may look weak but I think it is moving toward the right direction if we consider that GNU ld from binutils 2.22 defaulted to --no-copy-dt-needed-entries (doing less shared object traversal for more proper dependency tracking and avoiding unneeded work).

(In reply to Fangrui Song from comment #5)
> ld.bfd a.o --as-needed b.so
> 
> Let a.o define a function which will be called by b.so via dlopen. In this
> case, ld should export the function. This justification may look weak but I
> think it is moving toward the right direction if we consider that GNU ld
> from binutils 2.22 defaulted to --no-copy-dt-needed-entries (doing less
> shared object traversal for more proper dependency tracking and avoiding
> unneeded work).

LD creates dynamic section only if dynamic relocation is needed.
For this test, since no dynamic relocation is needed, there is no
dynamic section.  Since there is no dynamic section, there is no
dynamic symbol table.

(In reply to H.J. Lu from comment #6)
> (In reply to Fangrui Song from comment #5)
> > ld.bfd a.o --as-needed b.so
> > 
> > Let a.o define a function which will be called by b.so via dlopen. In this
> > case, ld should export the function. This justification may look weak but I
> > think it is moving toward the right direction if we consider that GNU ld
> > from binutils 2.22 defaulted to --no-copy-dt-needed-entries (doing less
> > shared object traversal for more proper dependency tracking and avoiding
> > unneeded work).
> 
> LD creates dynamic section only if dynamic relocation is needed.
> For this test, since no dynamic relocation is needed, there is no
> dynamic section.  Since there is no dynamic section, there is no
> dynamic symbol table.



>a.c <<e cat
 #include <dlfcn.h>
 int foo() { return 42; }
 int main() {
   void *h = dlopen("./b.so", RTLD_LAZY);
   int (*bar)(void) = dlsym(h, "bar");
   return bar();
 }
e
>b.c <<e cat
 int foo();
 int bar() { return foo(); }
e

cc -fuse-ld=bfd -shared -fPIC b.c -ldl -o b.so
cc -fuse-ld=bfd -pie -fPIE a.c -Wl,--push-state -Wl,--as-needed ./b.so -Wl,--pop-state -ldl

./a.out => symbol lookup error: ./b.so: undefined symbol: foo

-fuse-ld=gold or -fuse-ld=lld is good.

(In reply to Fangrui Song from comment #7)
> 
> >a.c <<e cat
>  #include <dlfcn.h>
>  int foo() { return 42; }
>  int main() {
>    void *h = dlopen("./b.so", RTLD_LAZY);
>    int (*bar)(void) = dlsym(h, "bar");
>    return bar();
>  }
> e
> >b.c <<e cat
>  int foo();
>  int bar() { return foo(); }
> e
> 
> cc -fuse-ld=bfd -shared -fPIC b.c -ldl -o b.so
> cc -fuse-ld=bfd -pie -fPIE a.c -Wl,--push-state -Wl,--as-needed ./b.so
> -Wl,--pop-state -ldl
> 
> ./a.out => symbol lookup error: ./b.so: undefined symbol: foo
> 
> -fuse-ld=gold or -fuse-ld=lld is good.

If it is the only use case, why not use

'--dynamic-list=DYNAMIC-LIST-FILE'
     Specify the name of a dynamic list file to the linker.  This is
     typically used when creating shared libraries to specify a list of
     global symbols whose references shouldn't be bound to the
     definition within the shared library, or creating dynamically
     linked executables to specify a list of symbols which should be
     added to the symbol table in the executable.  This option is only
     meaningful on ELF platforms which support shared libraries.

I think ld.bfd is completely fine to not export exe symbols only referenced by
mentioned but not otherwise needed libraries.  It's follows from traditional behaviour that executables don't export any symbols, which aren't obviously needed
in a static linking model, which is why -E exists.  I could a libararies that
isn't necessary by anything from the executable containing a back-reference to
the executable to not be obvious.  If you really need to support this situation
you would normally need to use -E, which btw is documented to sometime be necessary with dlopen games:

       -E
           ...
           If you use "dlopen" to load a dynamic object which needs to refer
           back to the symbols defined by the program, rather than some other
           dynamic object, then you will probably need to use this option when
           linking the program itself.

The more controled way for this is --dynamic-list.

Doing what you suggest would break the following invariant: you can remove any
unneeded as-needed -lxyz arguments from the link command and end up with the same
binary.  This is basically the set of libraries that 'ldd -u' would print, and is
why as-needed was implement to start with, to save that manual manual work.

(In reply to Michael Matz from comment #9)

I filed the bug not to find an alternative solution. I am wary of the semantics of --export-dynamic, --dynamic-list (and contributed the recent --export-dynamic-symbol --export-dynamic-symbol{,-list} BTW).

First, this is already a problem with --allow-shlib-undefined. Now the question is whether it is also a problem of --no-allow-shlib-undefined. My reasoning is that placing a shared object on the linker command line is an explicit intention that its referenced symbols should be exported, even if the shared object itself is unneeded (in terms of --as-needed).

(In reply to Fangrui Song from comment #10)
> (In reply to Michael Matz from comment #9)
> 
> I filed the bug not to find an alternative solution. I am wary of the
> semantics of --export-dynamic, --dynamic-list (and contributed the recent
> --export-dynamic-symbol --export-dynamic-symbol{,-list} BTW).
> 
> First, this is already a problem with --allow-shlib-undefined. Now the
> question is whether it is also a problem of --no-allow-shlib-undefined. My
> reasoning is that placing a shared object on the linker command line is an
> explicit intention that its referenced symbols should be exported, even if
> the shared object itself is unneeded (in terms of --as-needed).

You want to export symbols referenced by unused shared libraries which
may be dlopened.  But not all unused shared libraries will be dlopened.
I think this new behavior should be controlled by a new explicit option
if this behavior is desirable.