Re: Unreviewed cygwin/mingw dllimport patch for PRs 5287. 7910,11021

[Jason Merrill <jason at redhat dot com>]

On Thu, 12 Jun 2003 08:20:42 +1000 (EST), Danny Smith <danny_r_smith_2001@yahoo.co.nz> wrote:

> My reason for the test for TREE_STATIC of dllimport'd variables in this:
>
> if (is_attribute_p ("dllimport", name)) 
>     &&TREE_CODE (node) == VAR_DECL)
>   {
>     if (!TREE_STATIC (node))
>      /* This is needed for declarations of variables within functions */
>       TREE_PUBLIC (node) = 1; 
>     DECL_EXTERNAL (node) = 1;
>   }
>
> /* This is for all dllimport/export'd symbols */
> if (! TREE_PUBLIC (node))
>    error ("external linkage required")
>
>
> is to allow this, by setting TREE_PUBLIC as well DECL_EXTERNAL:
>
> void foo()
> {
>   __attribute__((dllimport))
>   int foovar;     // OK,  implicit "extern" 
>   foovar++;
> }

That's horrible.  That should be an error; foovar is an automatic variable.
Does VC++ allow this?

> but fail this  by refusing to set TREE_PUBLIC because of explicit
> static 
>
> void bar()
> {
>   __attribute__((dllimport))
>   static int imp_var;   // { dg-error "external linkage required" }
>   imp_var++;
> }

It might actually make sense to support this sort of usage on statics in
inline functions, since they need to be shared between all inlined copies
of the function regardless of DLL.

> and also fail all other cases (dllexported vars and functions, dllimported
> functions) where TREE_PUBLIC is not already set.

Agreed.

>> >> !       /* Turn off importing C++ virtual methods to able to create 
>> >> ! 	 vtables using thunks. */
>> >> !       else if (TREE_CODE (TREE_TYPE (decl)) == METHOD_TYPE
>> >> ! 	       && DECL_VIRTUAL_P (decl))
>> >> !         {
>> >> !           return 0;
>> >> !         }
>[...]
> The abort occurs  for the vtable entry for B::vfunc.
> Beacuse of the dllimport, we cannot use a pointer to the function as
> constant address, so  
>
>  __attribute__((dllimport)) foo();
>  void* pfn =  (void*) foo;
>
> causes problems. 

But if we don't specify dllimport, the linker generates a thunk in the
executable which does have a constant address?  OK, perhaps that is the
best solution.

Jason