[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
- Re: [autoconf] Re: pkg-config wisdom, (continued)
- Re: pkg-config wisdom, Matěj Týč, 2009/10/25
- AC_SEARCH_LIBS and non-cdecl calling conventions (was: pkg-config wisdom), Ralf Wildenhues, 2009/10/26
- Re: pkg-config wisdom, John Calcote, 2009/10/26
- Re: pkg-config wisdom, Matěj Týč, 2009/10/26
- AC_SEARCH_LIBS and non-cdecl calling conventions (was: pkg-config wisdom), Ralf Wildenhues, 2009/10/26
- Re: AC_SEARCH_LIBS and non-cdecl calling conventions (was: pkg-config wisdom), Matěj Týč, 2009/10/27
- Re: AC_SEARCH_LIBS and non-cdecl calling conventions, John Calcote, 2009/10/27
- Re: AC_SEARCH_LIBS and non-cdecl calling conventions, Ralf Wildenhues, 2009/10/27
- Re: AC_SEARCH_LIBS and non-cdecl calling conventions,
John Calcote <=