Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Message-Id: <199911261833.MAA14295@hp2.xraylith.wisc.edu>
To: geoff schmidt <gschmidt AT mit DOT edu>
cc: cygwin AT sourceware DOT cygnus DOT com, gcc AT gcc DOT gnu DOT org
Subject: Re: Workaround for virtual function/dllimport bug, also patch guidance request 
In-reply-to: Your message of "Thu, 25 Nov 1999 00:45:44 EST."
             <199911250545 DOT AAA20655 AT ten-thousand-dollar-bill DOT mit DOT edu> 
Date: Fri, 26 Nov 1999 12:33:25 -0600
From: Mumit Khan <khan AT NanoTech DOT Wisc DOT EDU>

geoff schmidt <gschmidt AT MIT DOT EDU> writes:
> 
> Since this has come up on the list before, if you're like me and have
> something you really want to compile, a crude but functional
> workaround is to add
> 
>   /* Don't let any functions get dllimport'd */
>   if (TREE_CODE (decl) == FUNCTION_DECL)
>     return 0;
> 
>   /* Don't let vtables get dllimport'd; it confuses the assembler */
>   if (TREE_CODE (decl) == VAR_DECL
>       && DECL_VIRTUAL_P (decl))
>     return 0;
> 
> to the beginning of i386_pe_dllimport_p in winnt.c.  With this patch
> I've successfully compiled and used a large OOP GUI framework with
> lots of inline and virtual functions as a DLL.  Only tested with
> -fvtable-thunks.

I dug through MSVC's output a bit, and it does something similar[1]
I'm going to try out your change and see if it's indeed the solution. 
I actually had this change way back (winnt.c still has code commented 
out from that experiment), but was never quite sure if it was the right 
thing to do or not.  

Thanks again for working on this problem. 

[1] MSVC's language front-ends understand the dllimport/dllexport 
directives, and do quite a bit more. One example is the following
code:

  /* top level. */
  __declspec(dllimport) extern int foo();
  int (*bar) () = foo;

this will emit different code in C and C++, but that's awkward to do in
language-independent GCC backend in the current implemention in winnt.c.
C will use the thunk (foo), and C++ will use __imp__foo to initialize
bar.

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com