libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: improve support for building DLLs on cygwin and mingw


From: Bruno Haible
Subject: Re: improve support for building DLLs on cygwin and mingw
Date: Wed, 6 Sep 2006 18:37:08 +0200
User-agent: KMail/1.9.1

Danny Smith wrote:
> <quote>
> ...
> 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

The same indirections happen on ELF systems:

externfunc2:
        pushl   %ebp
        movl    %esp, %ebp
        pushl   %ebx
        subl    $4, %esp
        call    __i686.get_pc_thunk.bx
        addl    $_GLOBAL_OFFSET_TABLE_, %ebx
        movl    $0, (%esp)
        call    address@hidden             <<< imported
        movl    8(%ebp), %ecx
        movl    address@hidden(%ebx), %edx  <<< imported
        addl    (%edx,%ecx,4), %eax
        addl    $4, %esp
        popl    %ebx
        popl    %ebp
        ret
...
.globl externvar  <<< exported
        .data
        .align 4

And it doesn't yield "ambiguities" on ELF systems.

> There is dangerous ambiguity.
> In the past this kind of ambiguity cause most of the dllimport-related
> ICE's in GCC.

I assume that GCC has enough maintainers to fix ICEs inside GCC.

> Does the client really want to resolve the two symbols using dllimport
> semantics?

Sure. If someone makes a reference to 'externvar' from within a DLL,
and it is also defined in the DLL, it's hard to imagine that he would
_not_ want to use the definition from the DLL.

> With unit-a-time optimizations, we delay adding the attribute until the
> whole unit is processed.

Nice, this allows to actually optimize away the indirection.

> which is probably what the user wanted. 
>  Maybe not.
> Maybe the user really just made a [im|ex] typo.

I propose to make 'dllexport' unnecessary, and to make it possible to
use 'dllimport' everywhere where the users were used to write either
'dllimport' or 'dllexport', depending on the compilation pass and unit.
Your counterargument is that he might wanted to see a warning which
reminds him to use 'dllexport' - but this is now unnecessary. This is
precisely the point of the simplification.

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]