This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [PING] [PATCH,i386][4.3][RFC] PIC Generation on windows/cygwin
- From: Danny Smith <dannysmith at clear dot net dot nz>
- To: 'Murali Vemulapati' <murali dot vemulapati at gmail dot com>, gcc-patches at gcc dot gnu dot org
- Date: Sat, 10 Feb 2007 23:14:51 +1300
- Subject: RE: [PING] [PATCH,i386][4.3][RFC] PIC Generation on windows/cygwin
> -----Original Message-----
> From: gcc-patches-owner@gcc.gnu.org
> [mailto:gcc-patches-owner@gcc.gnu.org] On Behalf Of Murali Vemulapati
> Sent: Friday, 9 February 2007 7:36 a.m.
> To: gcc-patches@gcc.gnu.org
> Subject: [PING] [PATCH,i386][4.3][RFC] PIC Generation on
> windows/cygwin
>
>
> Can somebody please review and/or approve this patch for i386/cygwin?
>
> Thanks
> Murali
>
> http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00117.html
Hello Murali,
Apart from some formatting issues I have a concern about how this breaks
dllimport-override semantics, ie a non-dllimport declaration should
override a dllimport one, but doesn't with your implementation of pic.
example:
========================================================================
=
#include <stdio.h> // which declares
// __declspec(dllimport) int __cdecl printf (const char*, ...);
// override the dllimport'd std (msvcrt.dll) function with an
alternative
// that we define in this file or elsewhere
int __cdecl printf (const char* , ...);
int foo () {return printf ("Hello world\n");}
========================================================================
=
In above we want to use out own (non-dllimport) version of printf,
but instead we get the std MSVCRT dllimport if compiled with -fpic:
LC0:
.string "Hello world\n"
.text
.globl _foo
.def _foo; .scl 2; .type 32; .endef
_foo:
pushl %ebp
movl %esp, %ebp
pushl %ebx
subl $4, %esp
call L3
L3:
popl %ebx
leal LC0-L3(%ebx), %eax
movl %eax, (%esp)
movl __imp__printf-L3(%ebx), %eax <<< dllimport from std
MSCVRT.dll
call *%eax
addl $4, %esp
popl %ebx
popl %ebp
ret
I have a suspicion that, due to something like above, any dll built with
-fpic will have problem with the way atexit is implemented for dll's in
mingw32 startfiles.
Could you publish (or send privately) a preview of the ld component of
this patch
so I can test my suspicion?
Danny