[Top][All Lists]
[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