VARARG

[aw27]

It produces the warnings when you BUILD.
IT does not produce warnings when you press F5 to debug-run, because it is assumed that you already know what you are doing (which is not case  ).

[jj2007]

It produces the warnings when you BUILD.

[aw27]

We already know that you always use all sorts of magic tricks to defend your unrealistic  theories.  :lol:

Code Select Expand


1>------ Rebuild All started: Project: ConsoleApplication1, Configuration: Release x64 ------
1>  ConsoleApplication1.cpp
1>ConsoleApplication1.cpp(16): warning C4305: 'initializing': truncation from '__int64' to 'long'
1>ConsoleApplication1.cpp(16): warning C4309: 'initializing': truncation of constant value
1>ConsoleApplication1.cpp(27): warning C4305: 'argument': truncation from '__int64' to 'long'
1>ConsoleApplication1.cpp(27): warning C4309: 'argument': truncation of constant value
1>  stdafx.cpp
1>  Generating code
1>  All 6 functions were compiled because no usable IPDB/IOBJ from previous compilation was found.
1>  Finished generating code
1>  ConsoleApplication1.vcxproj -> C:\Users\Jose\Documents\Visual Studio 2015\Projects\ConsoleApplication1\x64\Release\ConsoleApplication1.exe
1>  ConsoleApplication1.vcxproj -> C:\Users\Jose\Documents\Visual Studio 2015\Projects\ConsoleApplication1\x64\Release\ConsoleApplication1.pdb (Full PDB)
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========


[jj2007]

We already know that you always use all sorts of magic tricks to defend your unrealistic  theories.  :lol:

I use default settings, inter alia -W3. Glad to see that it works for you :icon_mrgreen:

[aw27]

IGlad to see that it works for you :icon_mrgreen:

000000013FF71100 | 49 B9 88 88 88 88 88 88 88 88 | movabs r9, 8888888888888888 | correct!

I have the strange feeling that you are cheating all the time. Since when does Visual Studio use GAS instructions, I mean movabs?  ::)

[jj2007]

Of course, I love cheating. And feeding trolls :icon_mrgreen:

Code Select Expand

000000013F4610AC | BA 66 06 00 00                    | mov edx, 666                       |
000000013F4610B1 | 49 B9 88 88 88 88 88 88 88 88     | movabs r9, 8888888888888888        |
000000013F4610BB | C7 44 24 20 11 01 00 00           | mov dword ptr ss:[rsp+20], 111     |

[aw27]

Of course, I love cheating. And feeding trolls :icon_mrgreen:

Code Select Expand

000000013F4610AC | BA 66 06 00 00                    | mov edx, 666                       |
000000013F4610B1 | 49 B9 88 88 88 88 88 88 88 88     | movabs r9, 8888888888888888        |
000000013F4610BB | C7 44 24 20 11 01 00 00           | mov dword ptr ss:[rsp+20], 111     |

I got it now, you are using one of those crappy disassemblers from github.   :lol:
mov dword ptr ss:[rsp+20], 111 is also lovely. 

[jj2007]

I got it now, you are using one of those crappy disassemblers from github.   :lol:
mov dword ptr ss:[rsp+20], 111 is also lovely. 

You shouldn't underestimate these tools. Actually, these crappy debuggers (not disassemblers) emulate a whole fake CPU: When they reach that address, and you step through the code, r9 fills magically with 8888888888888888, and memory at [rsp+20] fills with 111. Imagine what a giant programming effort is behind such an emulator 8)

[aw27]

You shouldn't underestimate these tools. Actually, these crappy debuggers (not disassemblers) emulate a whole fake CPU: When they reach that address, and you step through the code, r9 fills magically with 8888888888888888, and memory at [rsp+20] fills with 111. Imagine what a giant programming effort is behind such an emulator 8)

I am not an aficionado of magic debugger/emulators for fake CPUs. 

[hutch--]

Ha ha, the last disassembler I really liked was 1990 CodeView and used to write code formatted the same way. Now ALA 1998 - 2000 NuMega SoftIce was the genuine boys toy but later versions of Windows were pigs to get any form of debugger working because of their protected mode architecture. What I really need is a post mortem debugger which tells you where an app crashes which is far more use to me. The old DrWatson worked really well at this task but the later Win7 and 10 versions want to dump a pile of high level chyte and send if back to Microsoft.

These days I rarely ever use one, they are easy enough to defeat in security terms and are a lot slower than console output or even message boxes. The real use I have is for a decent disassembler that outputs plain text, ArkDasm barely does the job but it was really useful when I was designing the stack layout and call automation (invoke) macros for 64 but MASM.

[jj2007]

What I really need is a post mortem debugger which tells you where an app crashes

That is actually possible with x64dbg: Options/Preferences/Misc/Set x64dbg as Just In Time Debugger (as usual, they have ruthlessly stolen that feature from OllyDbg).

When the code crashes e.g. because of an idiv 0, see screenshot below, the grey box to the right appears; click on debug and hit F8 a couple of times, and voilà, here it is:

Code Select Expand

0000000140001089   | 33 C9              | xor ecx,ecx                             |
000000014000108B   | F7 F9              | idiv ecx                                |
000000014000108D   | 48 8D 15 A5 1F 00  | lea rdx,qword ptr ds:[140003039]        | 140003039:"Wow, it works!!"
0000000140001094   | 49 C7 C1 00 00 01  | mov r9,10000                            |
000000014000109B   | 4C 8D 05 A7 1F 00  | lea r8,qword ptr ds:[140003049]         | 140003049:"Hi"
00000001400010A2   | 33 C9              | xor ecx,ecx                             |
00000001400010A4   | FF 15 B6 20 00 00  | call qword ptr ds:[<&MessageBoxA>]      |

[aw27]

That is actually possible with x64dbg: Options/Preferences/Misc/Set x64dbg as Just In Time Debugger (as usual, they have ruthlessly stolen that feature from OllyDbg).

Ahaha  :lol:
But this is not Post-Mortem, the program is still alive. What these github debugger/emulators do is go through the stack trace till where the exception happened.
Windbg does not even let the program crash, it quietly breaks where the exception happened (so they are called 2nd chance exceptions, the debugger gets the second chance to see it live).
This is the difference between a professional tool and a colorful toy downloaded from github.
 
Post-Mortem is working through crash dumps. Here again, only Windbg can do it.

[jj2007]

.... till where the exception happened.

Which is usually the only aspect that I am interested in

[Biterider]

Hi
Coming back to VARARG, I noticed that floating point arguments passed as VARARG are stored in GP-Registers and not, as I would expect, in XMM regs. Is that the intended way it should work?

Code Select Expand


.xmm
option casemap:none
option dotname     
option frame:auto   
option win64:8     
option stackbase:rsp




.code


Test1 proc Arg1:QWORD, Args:VARARG
    mov rax, Arg1
    ret
Test1 endp




start proc
    invoke Test1, 102.54, REAL4 ptr 1.234, REAL8 ptr 1.234
    ret
start endp


end start



Test1 proc Arg1:QWORD, Args:VARARG
mov         qword ptr [Arg1],rcx 
mov         qword ptr [Args],rdx 
mov         qword ptr [rsp+18h],r8 
mov         qword ptr [rsp+20h],r9 
    mov rax, Arg1
mov         rax,qword ptr [Arg1] 
    ret
ret 
Test1 endp

The disassembly looks like

Code Select Expand


start proc
sub         rsp,28h 
    invoke Test1, 102.54, REAL4 ptr 1.234, REAL8 ptr 1.234
mov         r8,3FF3BE76C8B43958h 
mov         edx,3F9DF3B6h 
mov         rcx,42CD147Bh 
call        Test1 (0811000h) 
    ret
add         rsp,28h 
ret 


I'm not sure why the callee is saving all regs into the homing area. Has it something to do with the VARARG feature?


Biterider

[johnsa]

Yes it is. the items in vararg are effectively untyped, so they're passed in register and then stored in home-spaces and further stack spaces for consistency.
So it would be the first argument that in some way would be required to determine the count and type of the variable arguments, which could then be found and processed from stack locations.