[Bug ld/9790] New: LD's "export everything" logic problematic

I'm from the ReactOS Project and we use LD for linking executables, DLLs and
also drivers.

In ld/pe-dll.c:646, LD checks whether we have an export table and whether the
component to be built is an executable.

This works pretty well for executables and DLLs, but is quite problematic for
drivers: They usually don't export anything, but also don't fall under
info->executable.
Thus, all of its functions are exported by default, which is certainly not the
right way to go.

--
           Summary: LD's "export everything" logic problematic
           Product: binutils
           Version: 2.20 (HEAD)
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ld
        AssignedTo: unassigned at sources dot redhat dot com
        ReportedBy: mail at colinfinck dot de
                CC: bug-binutils at gnu dot org
GCC target triplet: mingw32


http://sourceware.org/bugzilla/show_bug.cgi?id=9790

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


_______________________________________________
bug-binutils mailing list
bug-binutils@...
http://lists.gnu.org/mailman/listinfo/bug-binutils

------- Additional Comments From mail at colinfinck dot de  2009-01-26 21:25 -------
Created an attachment (id=3688)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=3688&action=view)
Proposed patch fixing this problem for us

We already use this patch for more than a year and it fixes the problem for us.


On the other hand, it also disables the "export everything" feature if someone
is building a DLL and pe_dll_export_everything is 0.
This is no problem for us as all our DLLs are supplied with a .def file (and in
fact, this is IMO the only correct way to go).

Nevertheless, some people might rely on this LD-specific behaviour (Microsoft's
linker doesn't provide such an "export everything" feature afaik).
Still, it should be possible for them to enable pe_dll_export_everything, so
that they get their stuff working like before.

--


http://sourceware.org/bugzilla/show_bug.cgi?id=9790

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


_______________________________________________
bug-binutils mailing list
bug-binutils@...
http://lists.gnu.org/mailman/listinfo/bug-binutils

------- Additional Comments From Kai dot Tietz at onevision dot com  2009-01-27 20:25 -------
This export all symbols is of some interest, if you work with obj-c on mingw
targets, so I don't see that this feature should be eliminated that easy.

The main problem you have is that drivers are treated like dll binaries. So I
think the better way to disable this feature for drivers is a command line
option to indicate this.

--


http://sourceware.org/bugzilla/show_bug.cgi?id=9790

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


_______________________________________________
bug-binutils mailing list
bug-binutils@...
http://lists.gnu.org/mailman/listinfo/bug-binutils

------- Additional Comments From mail at colinfinck dot de  2009-01-27 21:36 -------
(In reply to comment #2)
> So I think the better way to disable this feature for drivers is a
> command line option to indicate this.

On the other hand, those obj-c people could use the --export-all-symbols command
line option, which already exists for ages :-P

--


http://sourceware.org/bugzilla/show_bug.cgi?id=9790

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


_______________________________________________
bug-binutils mailing list
bug-binutils@...
http://lists.gnu.org/mailman/listinfo/bug-binutils

------- Additional Comments From mail at colinfinck dot de  2009-09-25 23:44 -------
This problem persists in current binutils versions, so we're still required to
use this patch and cannot use vanilla binutils. We're actually hitting this
problem, because all our NT-like drivers have to be linked with the same -shared
option, which is used for building DLLs.

Kai's suggestion of adding additional command line options has some
disadvantages in my opinion: If we add something like "--nt-driver", people
could be confused about its actual effect. Also, if there would ever be other
modules, which have to be built with -shared, but shall not export any symbols,
the name of this option wouldn't fit anymore and confuse people even more.
An option like "--dont-export-all-symbols" is also no reasonable solution as it
would be an addition to the already existing --export-all-symbols. If both
options would be present, people could be irritated and becoming unsure about
the default if none of them is specified.

So after all, I still prefer applying the patch I posted here. This would change
the default to exporting no symbols in all cases.
If you then need to export all symbols (like in the Obj-C case Kai pointed out),
the long-existing --export-all-symbols option could still be used.

CC'ing Kai, hope you don't mind..

--
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Kai dot Tietz at onevision
                   |                            |dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=9790

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


_______________________________________________
bug-binutils mailing list
bug-binutils@...
http://lists.gnu.org/mailman/listinfo/bug-binutils

------- Additional Comments From mail at colinfinck dot de  2009-09-26 00:51 -------
Created an attachment (id=4232)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4232&action=view)
Updated patch

This updated patch has been created against current binutils.
It also removes some now unneeded lines, since 'if (NE == 0)' is already
checked below.

--
           What    |Removed                     |Added
----------------------------------------------------------------------------
Attachment #3688 is|0                           |1
           obsolete|                            |


http://sourceware.org/bugzilla/show_bug.cgi?id=9790

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


_______________________________________________
bug-binutils mailing list
bug-binutils@...
http://lists.gnu.org/mailman/listinfo/bug-binutils

------- Additional Comments From d dot g dot gorbachev at gmail dot com  2009-10-03 00:28 -------
Created an attachment (id=4249)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4249&action=view)
Patch

This patch adds a new `--exclude-all-symbols' option. It does not affect the
existing behavior, thus more chances that it will be accepted. Both
`--export-all-symbols' and `--exclude-all-symbols' are needed, because it's a
3-way choice -- export everything, export nothing, and export something. When
these options are used together, `--exclude-all-symbols' takes precedence.

By the way, the description of auto-export behavior is not quite correct:

> If `--export-all-symbols' is not given explicitly on the
> command line, then the default auto-export behavior will be
> _disabled_ if either of the following are true:
>
>    * A DEF file is used.

> Using a DEF file turns off the normal auto-export behavior,
> unless the `--export-all-symbols' option is also used.

In reality, if a DEF file does not export any symbols, using it does not turn
auto-export off. (Having no talent of speaking, I do not dare to change the
documentation.)

Another way to fix this problem would be to modify the auto-export behavior in
accordance with the existing documentation.

--


http://sourceware.org/bugzilla/show_bug.cgi?id=9790

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


_______________________________________________
bug-binutils mailing list
bug-binutils@...
http://lists.gnu.org/mailman/listinfo/bug-binutils

------- Additional Comments From nickc at redhat dot com  2009-10-16 15:20 -------
Hi Dmitry,

  Thanks for the patch - I have applied it along with an addition to the ld/NEWS
file mentioning the new feature and the ld/ld.texinfo file describing the new
command line option.

Cheers
  Nick


--
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://sourceware.org/bugzilla/show_bug.cgi?id=9790

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


_______________________________________________
bug-binutils mailing list
bug-binutils@...
http://lists.gnu.org/mailman/listinfo/bug-binutils