[GHC] #5987: Too many symbols in ghc package DLL

[GHC]

#5987: Too many symbols in ghc package DLL
---------------------------------+----------------------------------------
        Reporter:  igloo         |                Owner:
            Type:  bug           |               Status:  new
        Priority:  normal        |            Milestone:  8.0.1
       Component:  Compiler      |              Version:  7.5
      Resolution:                |             Keywords:
Operating System:  Windows       |         Architecture:  Unknown/Multiple
 Type of failure:  None/Unknown  |            Test Case:
      Blocked By:                |             Blocking:  5355
 Related Tickets:                |  Differential Rev(s):
       Wiki Page:                |
---------------------------------+----------------------------------------

Comment (by rassilon):

 Replying to [comment:46 bgamari]:
 >
 > My understanding of this situation is that it is not an intrinsic
 limitation of PE. The relevant data structures are the `.edata` and
 `.idata` tables which are defined in sections 63 and 64 of the PE/COFF
 specification. The specification specifies that one means of referring to
 exported symbols is via a 16-bit ordinal. However, this is not the only
 way; if the lookup fails the loader will fall back to a standard name
 search. Indeed, Microsoft even explicitly says that ordinals
 [[https://msdn.microsoft.com/en-us/library/hyx1zcd3.aspx|are a legacy
 artifact]] and their use is discouraged in new code (this document
 describes the `.def` format, but the idea still applies),
 >

 Your understanding doesn't match my understanding of the PE/COFF
 specification. Page 75 of the 02/06/2013 version of the spec which is the
 page where the Export Ordinal Table of the `.edata` section is described.

 The section includes pseudo-code explaining how the SymbolRVA of a named
 symbol is determined:

 i = Search_ExportNameTable(ExportName);

 ordinal = ExportOrdinalTable[i];

 SymbolRVA = ExportAddressTable[ordinal - ordinalBase];

 So, the problem isn't with this pseudo-code, but the pseudo-code combined
 with the Export Ordinal Table being defined as:

 > >  `The export ordinal table is an array of 16-bit indexes into the
 address table.`

 This is especially sad, since the Address Table Entries field of the
 Export Directory Table is 32 bits of data.


 The text you quote below is from the syntax of .DEF files explaining why
 16-bit DLLs, didn't include exported symbol string names and utilized the
 ordinal number as the ONLY `API` between DLLs. The documentation you quote
 is recommending usage of string symbols for providing a cross-DLL `API`
 resolution and only using the ordinal `API` for legacy reasons. The
 documentation doesn't mean to imply that ordinals are optional (based on
 my reading of the PE/COFF sections about .edata).


 > > You can use @ordinal to specify that a number, and not the function
 name, will go into the DLL's export table. Many Windows DLLs export
 ordinals to support legacy code. It was common to use ordinals in 16-bit
 Windows code, because it can help minimize the size of a DLL. We don’t
 recommend exporting functions by ordinal unless your DLL’s clients need it
 for legacy support. Because the .LIB file will contain the mapping between
 the ordinal and the function, you can use the function name as you
 normally would in projects that use the DLL.
 >

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:48>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler