autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AC_SEARCH_LIBS and non-cdecl calling conventions


From: John Calcote
Subject: Re: AC_SEARCH_LIBS and non-cdecl calling conventions
Date: Tue, 27 Oct 2009 22:15:42 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4

Hi Ralf,

On 10/27/2009 3:41 PM, Ralf Wildenhues wrote:
In the current scheme, AC_CHECK_LIB only tries to*link*  a function
call, not to actually run the linked code.  There are two aspects here
to consider:

1) This might not be a sharp enough test to decide which calling
convention is used (i.e., linking may succeed, but running would fail).
2) It might depend upon the function whether a link with the currently
tested calling convention works: it might succeed with f1 but fail with
f2.

Now, I'm not even interested in (1) right now; and I am aware that
solving (1) in general is probably a tough problem.  All I want to know
is: is (2) not a problem, and is there only a finite set of name
mangling operations done by ways of C calling convention per compiler,
unlike is done for C++?

If the only exception to this is the number of arguments that is encoded
in the mangled name, then that might still be workable, but then it will
definitely not be cheap in the end.  Everything else can probably be
made pretty cheap, at least if the calling convention is the same for
all AC_CHECK_LIB* tests.

The number of arguments is not really an issue. I'm sorry if I made is sound that way. What is an issue with stdcall, fastcall, and others is the number of stack words used by those arguments. On a 4-byte per word system, often stdcall and fastcall will generate symbols containing values that are multiples of 4, like this:

stdcall: address@hidden, address@hidden, address@hidden
fastcall: @address@hidden, @address@hidden, @address@hidden

This is why it's a really good idea to let the compiler determine the imported symbol name based on the function prototype.

However, I don't like the idea of specifying a full function prototype either. I wish there were some way to import a symbol just using the symbol name. On *nix systems, and when using cdecl on Windows systems, the way it's currently done is about as universal as it gets. To declare a function as stdcall on Windows systems, the imported symbol prototype in the test code would have to be:

   void _stdcall function_name(param1, param2, ..., paramN);

That way the compiler could generate the appropriate symbol name:

   address@hidden     (on 32-bit systems)
   address@hidden     (on 64-bit systems)

John





reply via email to

[Prev in Thread] Current Thread [Next in Thread]