This is the mail archive of the mailing list for the Cygwin project.

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

Re: More DLL fun! [fwd: ]

On Thu, 15 Jul 1999, Robert Bresner wrote:

> Howdy again
> We're continuing our DLL battles here and here is another 
> question that has come up.. If anyone can help me out with 
> an answer here, I'd sure appreciate it.
> Mark Thompson wrote:
> > 
> > I am trying to compare 2 pointers to functions.
> > All I am looking for is if they match or not.
> > The pointers are to a function.
> > The function is in a DLL, and the first place to get the
> > function pointer is in an exe.
> > The following is kind of a code sample (kind of but not really).
> > 
> > In the exe.
> > Pass a function pointer to DllFunc1.
> > 
> > DllFunc1( DllFunc1 );
> > 
> > In The DLL
> > 
> > Void DllFunc1( FuncPtr func )
> > {
> >  . Do some processing
> >  if ( func != DllFunc1 )
> >   func( func ) ;
> > }
> > 
> > I know the above is a bad example,
> > but it will work for demonstration.
> > The passed parameter is not a pointer to the function DllFunc1,
> > Instead what we get is a pointer to the DLL relocation table.
> > This means that the comparison always fails.
> > If func is set to DllFunc, it continually calls itself ending up in
> > blowing the stack.
> > If we link this application statically, the comparison works
> > correctly.
> > 
> > Is there some way to make the comparison of  function pointers that
> > are in a
> > DLL actually compare the address of the function and not the address
> > of the
> > relocation table?

Both Emunele and Fergus have already provided some useful info, so I 
won't repeat those.

This is an issue of compiler-internal hacks. Microsoft compiler, and
others that *have to* conform to it, does some interesting things when
you take the address of a function imported from a DLL (see the
assembly to see what I mean), and GCC will not do that unless there
is a clean way of doing it.

The workaround for now is to compile these using -fnop-fun-dllimport
switch to GCC, which tells GCC to ignore dllimport attribute for
functions and let the import library handle the "jump".

One other place where this is very useful is the following C construct:
  /* global scope. */

  __declspec(dllimport) int dllfun ();
  int (* funcp) () = dllfun;

You have to use -mnop-fun-dllimport to get this to work under GCC. If
you want to get insight of what I call compiler-internal hack, look
at the assembly for the following:
  /* global scope. */

  __declspec(dllimport) int dllfun ();
  int (* funcp) () = dllfun;

  foo ()
    int (* funcp_local) () = dllfun;


Want to unsubscribe from this list?
Send a message to

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