Re: x64 Calling convetion(ABI) issues.

I'm piggy-backing to this thread one more general consideration:

despite the similarity between x86 and AMD64 as assembly syntax,
one thing that people often do not fully understand is the exception unwind
model
of AMD64, that is radically different, and that requires the
compiler/assembler
to properly describe the code regions, and the register usage in each code
region.
Writing anything that is not a leaf function in assembly is simply a
self-suicide task.
If may seem right per code inspection and average test usage, but, the first
time the OS will have to unwind throught that code, it may simply
double-fault,
Access Violate in kernel-mode, or have other unpredictable behaviors.
Please refrain from writing non leaf-entry functions in assembly,
that's the average recomendation.

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Sam" <joe@xxxxxxxxxx> wrote in message
news:Oe7aiFeoFHA.3256@xxxxxxxxxxxxxxxxxxxxxxx
> Thanks for the quick summary -- it is printed out and posted right on my
> wall!!
>
> "Ivan Brugiolo [MSFT]" <ivanbrug@xxxxxxxxxxxxxxxxxxxx> wrote in message
> news:eq4uZdboFHA.2152@xxxxxxxxxxxxxxxxxxxxxxx
>> > So have to rewrite the _asm session to C or intrinsic function.
>>
>> You can use an external *.ASM file that you can place in
>> an architecture specific folder, and then have build.exe to
>> pick-it up from the SOURCES file.
>>
>> You may want to check
>> http://www.microsoft.com/whdc/winhec/partners/64bitAMD.mspx
>>
>> And, as a quick summary
>> Parameter registers are rcx, rdx, r8, and r9. Stack pointer is rsp. The
>> usual x86 preserved registers are the same (rbx, rbp, rsi, rdi), in
> addition
>> to r12-r15. r10 and r11 are additional scratch registers.
>>
>> Unlike x86, methods will allocate all the stack space they need up front,
> so
>> a frame pointer (ebp) is normally not needed, and there are no push's or
>> pop's anywhere else in the method. 'k' does not even have a column for
> rbp.
>>
>> For more than 4 parameters, the values will be at the caller's rsp +
>> 0x20.
>> Unlike x86, the caller always controls space for the parameters - rsp is
>> always the same before and after any call. On x86, the non-register
>> parameters are pushed. On amd64, the space for the extra parameters will
> be
>> allocated at the start of the method, and at the call, they are mov'd
>> into
>> the stack with instructions like 'mov [rsp+0x20], rax'.
>>
>> By convention, parameters are usually saved at the caller's rsp. Ex. you
> can
>> find r8 at the callers rsp (this is where 'kv' gets it from). This is not
>> required though, and the values might not be saved in optimized builds.
>>
>> Structs are passed by reference if > 8 bytes. In other words, if it won't
>> fit in a register, it's passed by reference. Similarly, return values > 8
>> bytes require that the caller allocate a buffer, and the buffer is passed
> in
>> rcx. This means rcx/the first parameter is *not* always the 'this'
> pointer.
>>
>> Can you possibly post the `.fnentry <function_address>` output for
>> the function that do not pass ?
>>
>> --
>> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>> Use of any included script samples are subject to the terms specified at
>> http://www.microsoft.com/info/cpyright.htm
>>
>>
>> "Tonald" <Tonald@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>> news:4CA9D390-E331-45B1-8755-9B91EC16DF9D@xxxxxxxxxxxxxxxx
>> > _asm{...} is not allowed in 64bit DDK compiler.
>> > So have to rewrite the _asm session to C or intrinsic function.
>> > While, rewrite to C works fine, but rewrite to intrinsic
> funtion(complete
>> > assemble code) have some problems.
>> > In HCT 12.1, there is a x64 calling convention test, which complain
>> > that
>> > the
>> > intrinsic function is "leaf function can not call ....." "nested
> function
>> > can
>> > not modify ...."
>> > Some errors like that.
>> > THe intrinsic function works well while running, seems the errors come
>> > with
>> > some register using not match some format.
>> >
>> > After search in MSDN, did not find any helpful information.
>> > So, is there any body know how to write the intrinsic function
>> > correctly(can
>> > pass the HCT12.1's x64 calling convention tests)?
>> >
>> >
>>
>>
>
>


.

Relevant Pages

  • Re: 64Bit installation on a 500 GB Sata DRIVE
    ... just because it adds more hassle than it gains ... I have all the systems I use/admin in 64bits (amd64), ... plugins that won't work correctly on amd64, while they work fine on x86. ... If it's really the amd64-kernel on x86 that's outperformed, ...
    (Debian-User)
  • Re: Two Click disassembly/reassembly
    ... > Map the extra x86 registers to memory. ... > As long as you've got indirection through a register and the ability to ... compiler can't handle here. ... rather than a line by line assembler. ...
    (alt.lang.asm)
  • [going OT] Re: 64Bit installation on a 500 GB Sata DRIVE
    ... I have all the systems I use/admin in 64bits (amd64), ... and Ubuntu, I don't feel any "hassle" anymore. ... plugins that won't work correctly on amd64, while they work fine on x86. ... I am pretty sure it's 64bits kernel and libs, ...
    (Debian-User)
  • Re: Linux X demo
    ... X programmer to correct the code. ... doesn't "move.l r1,r5", etc., guarantee that no x86 programmer ... How does one assemble it? ... my observations about how to compile or port HK x86 code are still ...
    (alt.lang.asm)
  • Re: Variadic functions calling variadic functions with the argument list, HLL bit shifts on LE proce
    ... >little-endian, and as well the low order bytes of the word are aliased ... >to specific sections of the register, and there are zillions of those ... So, on the x86 ... >size register aliases off of the x86. ...
    (comp.lang.c)