[MLton] symbol scopes

[Wesley W. Terpstra]

On Wed, Nov 12, 2008 at 7:56 PM, Wesley W. Terpstra <wesley at terpstra.ca> wrote:
>> I guess it is just for Win{32,64} that
>> the EXTERNAL/PUBLIC/PRIVATE macros map to different annotations
>
> Correct.
>
>> (though, I think, that is partly due to the fact that a single C declaration needs to
>> serve as both an export directive (for the definition) and an import
>> directive (for other uses)).
>
> No. They really do do different things as I explained above.

Sorry to double post, but I thought I should elaborate a bit more.

No annotation when accessing a symbol means: use _symname.
No annotation when defining a symbol means: declare it as _symname.

The dllimport annotation when accessing a symbol means: use *__imp__symname
Defining a symbol as dllimport has no effect (I personally think gcc
should error out).

The dllexport annotation when accessing a symbol means: use _symname.
The dllexport annotation when defining a symbol means: declare it as
_symname and add an entry to the section .drectve which lists
functions to export.

When a DLL is created, all symbols named in the .drectve are made
public. That means: the import library has an __imp__symname for each
of them, which will be overwritten by the runtime loader. I speculate
it also marks up the DLL to tell the loader what to write into these
__imp__ symbols from the import library. MinGW also adds a symname
proxy for functions.

Now suppose we did what you propose: make dllimport/export the same
tag. The definition of a function would be _symname, but uses of that
symbol within another object final built into the DSO would be called
__imp__symname. However, there is no __imp__symname in the resultin
DLL, so you would get a link error. Thus the two tags cannot apply to
the same symbol within a DSO.

A note: Windows defines the canonical address to be the point of
definition, which sounds sane, but is actually not true for most
platforms. That's why _symname works even for symbols you will export.
I already mentioned this is not true for ELF, where the canonical
address is actually the stub that appears in the executable, or the
executable's own definition (!!!). Don't believe me? Read the sysv abi
and cry. :-(