x64 Calling convetion(ABI) issues.
in [Device Drivers]
|
From: Tonald on 15 Aug 2005 03:16 _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)?
From: Ivan Brugiolo [MSFT] on 15 Aug 2005 12:35 > 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(a)discussions.microsoft.com> wrote in message news:4CA9D390-E331-45B1-8755-9B91EC16DF9D(a)microsoft.com... > _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)? > >
From: Sam on 15 Aug 2005 17:33 Thanks for the quick summary -- it is printed out and posted right on my wall!! "Ivan Brugiolo [MSFT]" <ivanbrug(a)online.microsoft.com> wrote in message news:eq4uZdboFHA.2152(a)TK2MSFTNGP14.phx.gbl... > > 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(a)discussions.microsoft.com> wrote in message > news:4CA9D390-E331-45B1-8755-9B91EC16DF9D(a)microsoft.com... > > _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)? > > > > > >
From: Ivan Brugiolo [MSFT] on 15 Aug 2005 19:34 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(a)nospam.org> wrote in message news:Oe7aiFeoFHA.3256(a)TK2MSFTNGP12.phx.gbl... > Thanks for the quick summary -- it is printed out and posted right on my > wall!! > > "Ivan Brugiolo [MSFT]" <ivanbrug(a)online.microsoft.com> wrote in message > news:eq4uZdboFHA.2152(a)TK2MSFTNGP14.phx.gbl... >> > 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(a)discussions.microsoft.com> wrote in message >> news:4CA9D390-E331-45B1-8755-9B91EC16DF9D(a)microsoft.com... >> > _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)? >> > >> > >> >> > >
From: Maxim S. Shatskih on 16 Aug 2005 01:22 > of AMD64, that is radically different, and that requires the > compiler/assembler > to properly describe the code regions IIRC "gcc" uses the same on x86 for C++ exceptions. This results in eliminating nearly any extra machine code use to enter and leave the exception frames. -- Maxim Shatskih, Windows DDK MVP StorageCraft Corporation maxim(a)storagecraft.com http://www.storagecraft.com
|
Next
|
Last
Pages: 1 2 Prev: USB device access via DeviceIoControl and WriteFile / ReadFile Next: PcCardConfig M Option |