Re: x64 Calling convetion(ABI) issues.

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: x64 Calling convetion(ABI) issues.
    ... > So have to rewrite the _asm session to C or intrinsic function. ... Unlike x86, methods will allocate all the stack space they need up front, so ...
    (microsoft.public.development.device.drivers)
  • x64 Calling convetion(ABI) issues.
    ... So have to rewrite the _asm session to C or intrinsic function. ... In HCT 12.1, there is a x64 calling convention test, which complain that the ...
    (microsoft.public.development.device.drivers)
Loading