Re: thin linking: "file is not of required architecture"
Re: thin linking: "file is not of required architecture"
- Subject: Re: thin linking: "file is not of required architecture"
- From: Jonas Maebe <email@hidden>
- Date: Wed, 23 Apr 2008 12:02:10 +0200
On 22 Apr 2008, at 23:49, Steve Checkoway wrote:
I'm unaware of any portable, high-level language that says anything
at all about caller or callee saved registers or even talks about
registers at all (C's register keyword notwithstanding). The fact
that the people who implemented the Pascal compilers went against
the hardware's stated conventions seems wrong to me.
In C, you are forced to perform the parameter cleanup in the caller
after every function call, because the callee doesn't necessarily know
the total size of the parameters pushed (due to potential varargs
parameters). In Pascal you don't have this problem (variable sized
"open array" parameters consist of a length and a pointer to the
array), so there you can put the parameter cleanup in the callee (so
it's included only once rather than every time the function is called).
Since the i386 ISA specifically includes an instruction which removes
the parameters from the stack (if you know their size) and returns to
the caller ("ret $parasize", with $parasize limited to 16 bit), I
doubt that using it actually went against the hardware's stated
conventions (especially in the days of Turbo Pascal and the likes).
But as far as "hardware's stated conventions" go, you always lose with
the i386. There is no single ABI for it, and there's a lot more than
just __cdecl vs __stdcall. There's also
* __fastcall (aka "register", eax, edx and ecx used for the first
three parameters depending on their type -- and depending on which
version of GCC you use, fastcall behaves slightly differently)
* __safecall (Windows-specific; don't know the exact details, but in
this case the actual result is --regardless of its type-- always
returned using a hidden pointer passed by the caller as the first
argument, and the function result register contains some success/
failure code)
* differences between Windows and ELF platforms (e.g. gcc for Windows
returns structs <= 8 bytes by value in edx:eax, while on Linux it
returns them using a hidden pointer passed by the caller)
* differences between Darwin and ELF platforms (Darwin returns structs
<= 8 bytes also by value, but only if their size is a power of 2;
Darwin requires that all ordinal parameters whose size is <=
sizeof(int) are sign/zero-extended to int while this is not required
on other Unices I know of)
* differences between different Windows compilers (Delphi stdcall and
gcc stdcall follow different rules for structs passed by value)
etc.
So in general, the i386 is simply one big mess as far as calling
conventions go. Blaming it on implementers of Pascal (or C, for that
matter) compilers does not even get near the actual problem...
The situation is fortunately much better on PPC and x86_64 (although
on x86_64 there are also differences between Win64 and the official
ABI, but at least all Unices I know of --including Darwin-- follow the
official ABI as published by AMD).
Jonas
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden