This is the mail archive of the libffi-discuss@sourceware.org mailing list for the libffi project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Questions regarding calling conventions


On 06/26/2012 11:21 AM, Elliott Darfink wrote:

> I've been using libffi recently and I have come up with several
> questions regarding the implemented calling conventions. The most
> recent version of libffi (3.0.11 as of now) implemented support for
> several new calling conventions, among these were thiscall, fastcall
> and MSVC cdecl on Windows x86.
> 
> I have yet to try these implementations, but so far I've only worked
> with libffi on Linux. What I am wondering though, how come these
> calling conventions aren't implemented on Linux x86?
> 
> Recently I've been working with a linux (GCC) library which features
> functions using the fastcall convention, and since libffi only
> supports fastcall on Windows, I can by no means call these functions
> using libffi. I'm aware of the fact that fastcall (and stdcall for
> that matter) is barely used on the Linux platform but considering
> that GCC have had support for the fastcall convention since version
> 3.4 (__attribute__((fastcall))), it's a shame there is not support
> for this.  Therefore I want to ask why this is not implemented?
> Perhaps it's because of its infrequent usage, but I would definitely
> appreciate such a feature (NOTE: GCC supports the stdcall convention
> as well)!
> 
> As I mentioned earlier, support was also added for the 'thiscall' on
> Windows x86 in the most recent release. As you all surely must know,
> the thiscall convention is special on the Windows platform (it
> pushes 'this' in the ECX register, the order is RTL and it is the
> callee that cleans the stack) whilst GCC uses the "ordinary" cdecl,
> but pushes the 'this' pointer implicitly as the first argument to
> the function.
> 
> Since GCC's thiscall convention is so similar to the cdecl convention, 
> one could easily call a member
> function specifying FFI_DEFAULT_ABI on Linux x86, but I have two questions:
> 
>      1. How come the 'thiscall' isn't implemented on Linux x86 (even
> though it's so similar to the cdecl convention)? For the sake of
> uniformity (and perhaps brevity?) it would ease the process of
> cross-platform applications, if this were to be implemented on Linux
> x86 as well. Perhaps it's not implemented because libffi is not
> "high-level" enough?

The major purpose of libffi is to allow calling of functions from
interpreted languages.  There is an ABI used on x86 UNIX systems, and
it makes sense that it be the one that libffi supports.  All system
libraries use this ABI.
http://refspecs.linuxbase.org/elf/abi386-4.pdf

I don't think that anyone would strenuously object if you wanted to
add thiscall and fastcall to libffi on GNU/Linux, but the 32-bit x86
system is these days only maintained as a legacy architecture.  x86_64
is the future, and it has a much more efficient calling convention.

> I also want to ask if there is any possibility of having
> ffi_prep_cif_var without the 'ntotalargs' argument?  Even though I'm
> not an expert on calling conventions, from what I know there is no
> way for the callee to know the amount of arguments passed to a
> variadic function (which makes my request impossible to implement).

I can't immediately think of any way to do it.  If you're going to
construct an arglist on the stack, you need to know how long it is.

> NOTE: For those of you that don't know, you 'detour' functions by 
> replacing the first 5 bytes of a function with a 'call <address>'

In which case you can solve the problem by popping the return address
from the stack and just using the arglist that's already there.
Either that or copying a large block of memory from the stack and
using it as is.

Andrew.


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