This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]