RE: improve support for building DLLs on cygwin and mingw

[Danny Smith]

> You find complete details about this approach in
>   http://www.haible.de/bruno/woe32dll.html
> 

<quote>
extern __declspec(dllimport) int externvar[5];
extern __declspec(dllimport) int externfunc(int);

int externfunc2 (int x)
{
  return externvar[x] + externfunc (0);
}

int externvar[5] = { 11, 22, 33, 44, 55 };

int externfunc (int x)
{
  if (x == 0)
    return 42;
  else
    return externfunc2 (x);
}
extern __declspec(dllimport) int externvar[5];
extern __declspec(dllimport) int externfunc(int);

int externfunc2 (int x)
{
  return externvar[x] + externfunc (0);
}

int externvar[5] = { 11, 22, 33, 44, 55 };

int externfunc (int x)
{
  if (x == 0)
    return 42;
  else
    return externfunc2 (x);
}

gcc reports warnings:

warning: 'externvar' defined locally after being referenced with
dllimport linkage
warning: 'externfunc' defined locally after being referenced with
dllimport linkage

Once libtool is changed to not cause link errors for self-references,
there is no need any more for this warning. gcc should remove this
warning.
</quote>

Are you sure about that.

The reason that gcc emits these warnings is this:
gcc -S dllimp.c

        .file   "dllimp.c"
        .text
.globl _externfunc2
        .def    _externfunc2;   .scl    2;      .type   32;     .endef
_externfunc2:
        pushl   %ebp
        movl    %esp, %ebp
        pushl   %ebx
        subl    $4, %esp
        movl    8(%ebp), %edx
        movl    __imp__externvar, %eax  <<< imported
        movl    (%eax,%edx,4), %ebx
        movl    $0, (%esp)
        movl    __imp__externfunc, %eax <<< imported
        call    *%eax
        leal    (%ebx,%eax), %eax
        addl    $4, %esp
        popl    %ebx
        popl    %ebp
        ret
.globl _externvar  <<< exported
        .data
        .align 4
_externvar:
        .long   11
        .long   22
        .long   33
        .long   44
        .long   55
        .text
.globl _externfunc <<< exported
        .def    _externfunc;    .scl    2;      .type   32;     .endef
_externfunc:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $8, %esp
        cmpl    $0, 8(%ebp)
        jne     L4
        movl    $42, -4(%ebp)
        jmp     L6
L4:
        movl    8(%ebp), %eax
        movl    %eax, (%esp)
        call    _externfunc2
        movl    %eax, -4(%ebp)
L6:
        movl    -4(%ebp), %eax
        leave
        ret

There is dangerous ambiguity.
In the past this kind of ambiguity cause most of the dllimport-related
ICE's in GCC.
Does the client really want to resolve the two symbols using dllimport
semantics?

With unit-a-time optimizations, we delay adding the attribute until the
whole unit
is processed.
 
gcc -O2  -funit-at-a-time -S dllimp.c

        .file   "dllimp.c"
        .text
        .p2align 4,,15
.globl _externfunc
        .def    _externfunc;    .scl    2;      .type   32;     .endef
_externfunc:
        pushl   %ebp
        movl    %esp, %ebp
        movl    8(%ebp), %eax
        testl   %eax, %eax
        jne     L8
        popl    %ebp
        movl    $42, %eax
        ret
        .p2align 4,,7
L8:
        popl    %ebp
        jmp     _externfunc2
        .p2align 4,,15
.globl _externfunc2
        .def    _externfunc2;   .scl    2;      .type   32;     .endef
_externfunc2:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $8, %esp
        movl    $0, (%esp)
        call    _externfunc
        movl    8(%ebp), %edx
        movl    _externvar(,%edx,4), %ecx
        leave
        addl    %ecx, %eax
        ret
.globl _externvar
        .data
        .align 4
_externvar:
        .long   11
        .long   22
        .long   33
        .long   44
        .long   55

which is probably what the user wanted. 
 Maybe not.
Maybe the user really just made a [im|ex] typo.
I think this is what MSVC compiler does,  warning that dllimport has
been 
replaced by dllexport.

You may be interested in the dllimport/export sematics used by the SH
symbian OS.  See the comfig/gcc/sh/symbian.c for a quick overview.
There s a complete spec available on the web, but I've misplaced the
reference.