Questions regarding calling conventions

Elliott Darfink elliott.darfink@gmail.com
Tue Jun 26 10:21:00 GMT 2012


Hi,

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?

     2. Last but not least, since I'm already here, how does one supply 
the 'this' pointer using FFI_THISCALL on
         Windows 32bit? Is it passed as the first argument in the 
ffi_call 'arguments' array or have I got it all wrong?

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).

The reason I'm asking is because I'm probably going to use libffi for a 
detouring project of mine later on,
and if I were to detour a variadic function, there would be no 
possibility for me to know the total amount
of arguments passed to the 'detoured' function.

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>'

Disclaimer: I'm not so familiar with mailing-lists so excuse me for any 
technical mistakes.



More information about the Libffi-discuss mailing list