x64 ABI vs. x86 ABI (aka Calling Conventions for AMD64 & EM64T)

re: x64 ABI vs. x86 ABI (aka Calling Conventions for AMD64 & EM64T)

anonymous coward — Sat, 01 Jul 2006 01:02:43 GMT

Please add these links to your blog:

http://msdn.microsoft.com/library/en-us/debug/base/structured_exception_handling_functions.asp

http://msdn2.microsoft.com/en-us/library/7kcdt6fy.aspx

This because my fellow workers started using your blog as ultimate source of reality and imho this is dumb.

re: x64 ABI vs. x86 ABI (aka Calling Conventions for AMD64 & EM64T)

Slava — Tue, 11 Apr 2006 02:56:04 GMT

OK, it seems that _local_unwind just calls RtlUnwindEx with appropriate parameters.

re: x64 ABI vs. x86 ABI (aka Calling Conventions for AMD64 & EM64T)

Slava — Sat, 08 Apr 2006 01:48:16 GMT

Hi Kevin,

Could you tell anything about _local_unwind routine? From some sources I know that it should be called every time the flow of control leaves guarded block of __try/__finally construct. It takes two arguments and it calls termination handler by itself.

But I found nothing about this routine in Microsoft documentation! It makes me feel bad :(

Please, give me any hints about it.
Thanks!

re: x64 ABI vs. x86 ABI (aka Calling Conventions for AMD64 & EM64T)

asdf — Fri, 17 Mar 2006 05:34:59 GMT

I forgot that my all time favorite example of this is:

HRESULT IDirect3DDevice9::SetRenderState(
D3DRENDERSTATETYPE State,
DWORD Value
);

Because the D3D programmers were too lazy to add another function that took a float, here is what their documentation says for a few render states:

"Values for the this render state are floating-point values. Because the IDirect3DDevice9::SetRenderState method accepts DWORD values, your application must cast a variable that contains the value, as shown in the following code example.

pDevice9->SetRenderState(D3DRS_FOGSTART, *((DWORD*) (&fFogStart)));"

Which assumes sizeof(DWORD) == sizeof(float) and alignof(dword) % alignof(float) == 0. But most importantly this is undefined due to aliasing. The only correct way is to use a memcpy (or equivalent).

re: x64 ABI vs. x86 ABI (aka Calling Conventions for AMD64 & EM64T)

asdf — Fri, 17 Mar 2006 05:23:41 GMT

- Why does *ABI* documentation mention malloc? That's a C runtime library function and has nothing to do with ABI.

- Why does it say "recommended alignment". It should just list the minimum alignment.

- The ABI documentation doesn't mention that function pointers may be allowed to be cast to data pointers. This is a divergence from the C standard.

- This ABI documentation says nothing about aliasing. The winapi is notoriously bad for getting const and aliasing wrong as far as the C standard is concerned. The two most common examples of broken aliasing in the winapi are:

int and long are the same representation on Windows so Microsoft programmers use these interchangably. The problem is that they are not interchangable as far as the C standard is concerned. Depending on which header files or versions of header files a module gets compiled with:

void foo(int *);

in one translation unit becomes

void foo(long *);

in another. This has huge reprocussions as far as the C standard is concerned and it also breaks the ODR of C++. A somewhat related annoyance was this one winapi header file that would do this (I don't know if this was the exact types, but it was similar):

typedef int ptrdiff_t;
typedef unsigned int size_t;

But on my compiler it was actually:

typedef long ptrdiff_t;
typedef unsigned long size_t;

And this would break my overloads and name mangling depending on the order of header files included. For example:

struct foo {
char & operator[](ptrdiff_t);
operator char *();
};

the *exact* type of ptrdiff_t is essential for the C++ compiler to resolve:

foo f;
f[0];

into the intended call.

The other common occurance is the void ** in the COM IUnknown::QueryInterface function. The dummy who designed it used void ** as (incorrectly) "generic pointer to pointer" instead of (correctly) "pointer to generic pointer" which breaks aliasing depending on what the correct code is. Unfortunately, I can't tell what the correct code is as I have seen a ton of different examples in the wild but I am convinced that the following is the *only* correct way because it's the only one guaranteed to work by the C++ standard no matter what weird machines it runs on:

HRESULT Foo::QueryInterface(quid_t g, void **ptr)
{
*ptr = 0;
if (q == BLAH_GUID)
ptr = static_cast<IBlah*>(this);
...
}

IBlah *blah;
void *ptr;
p->QueryInterface(BLAH_GUID, &ptr);
blah = static_cast<IBlah*>(ptr);
// or equivalently
blah = (void*)ptr;

Every other example is incorrect, including:

p->QueryInterface(blah_guid, (void**)&blah);

// or

p->QueryInterface(blah_guid, &ptr);
blah = reinterpret_cast<IBlah*>(ptr);

// or

HRESULT Foo::QueryInterface(quid_t g, void **ptr)
{
ptr = reinterpret_cast<IBlah*>(this);

// or

ptr = reinterpret_cast<void*>(static_cast<IBlah*>(this));

// or
*reinterpret_cast<IBlah**>(ptr) = this;

// etc.

}

re: x64 ABI vs. x86 ABI (aka Calling Conventions for AMD64 & EM64T)

Kevin Frei — Tue, 07 Mar 2006 21:46:03 GMT

BTW - there's no inline assembly because, well, it's a lot of work, and we didn't have a lot of time to do it in (at least it didn't seem that way at first). Inline assembly also tends to get in the way of the optimizer, and it also tends to let people write code that works most of the time, until they realize that they didn't understand the ABI, and now the code they deployed to customers can't properly handle exceptions, nor can they debug the crash dumps... We'll probably be adding inline asm support in the future (not the next product release, though). In the mean time, there is a pretty complete list of intrinsic functions in intrin.h...

re: x64 ABI vs. x86 ABI (aka Calling Conventions for AMD64 & EM64T)

Kevin Frei — Tue, 07 Mar 2006 21:04:20 GMT

That means that all functions must starts with a 2 byte instruction, and must be preceded by 6 bytes of padding. I'll write a new post about that in the next few days...

re: x64 ABI vs. x86 ABI (aka Calling Conventions for AMD64 & EM64T)

manhattan — Tue, 07 Mar 2006 07:00:17 GMT

Do you know what "hot-patchability" means ?

Quote:

"All x64 functions are required to be hot-patchable, in order to enable both high availability, and maximum security."

re: x64 ABI vs. x86 ABI (aka Calling Conventions for AMD64 & EM64T)

Billy Rose — Sun, 19 Feb 2006 20:35:34 GMT

How about some examples with extensive embedded comments for each line of code that handles all of the situations, i.e.: this is a leaf function with all of the data structures required, this is a non-leaf function with all data structures required, this is an exception handler with all required data structures, etc.

re: x64 ABI vs. x86 ABI (aka Calling Conventions for AMD64 & EM64T)

Bruce Frost — Tue, 09 Aug 2005 03:11:41 GMT

Very good so far. My problem is that the detailed information leaves out some of the most important details. I am well aware of how structured exception handling works internally in x86 32-bit but no idea what happens in 64-bit.

The official document is missing a description of where the unwind information is located and how to find the unwind information for a function at some location.

Also, it would help to describe how exception handling in X64 works in the same detail of the article by Matt Pietrek at:
http://www.microsoft.com/msj/0197/exception/exception.aspx