1

I'm trying to embedd my x64 assembler code into c++, as i know x64 __asm is not allowed in x64, so what i tried, is i made an asm defintion like this in func.asm:

.code
proc_testing PROC

push rcx
pop rcx

proc_testing ENDP
END

And in my C code, main.c:

#include "stdafx.h"

extern"C" void inline proc_testing();
int main()
{
    proc_testing();
    return 0;
}

I tought that inline keyword would make the compiler not to call proc_testing() but to place its code inside the main. Unfortunately it still make a call proc_testing. In masm you have a keyword MACRO also, but here i cannot use this, i get compilation error if use MACRO instead of PROC, i tried to do it like this:

.code
proc_testing MACRO
push rcx
pop rcx

proc_testing ENDM
END

This way i get an error: unmatched macro nesting.

So i have a two question actually:

1) Can the masm assembly in x64 in visual studio be inline? So when i use proc_testing(); it will not do the call proc_testing but actually place the code of proc_testing inside the main.

2) Can you make masm MACRO to work outside the .asm file? If So how can i achieve that?

So basically i need to get rid of the call and place the assembly code directly at link/compile time. The assembler code is generated dynamically using some engine, so i cannot use compiler intrinsics, i would need to rewrite the asm generator for that.

And finally, if all the variants are not possible, can i do an analogy of _asm _emit, to just place the machine code in hex, in the .text inside the specific places?

  • Making function inline makes sense only if function body is rather small so there is a benefit of replacing it's call with it's body. I somehow doubt that you assembly functions are that small and simple. – user7860670 Aug 16 '17 at 11:12
  • @VTT It is meant to be used as an anti-debugging method, i have generated lot of condition with jumps etc, they differ each time, they do all kind of instructions with loops, restoring original register values, that's why i don't want the `call` for each of them. As it would be easy to see that it's junk call – PastaWithGarlicOil Aug 16 '17 at 11:14
  • @VTT basically it changes the control flow graph, that's why its crucial to not make this calls, and iline all the generated blocks. In Mingw64 i had no problem doing that, but i'm not very familiar with msvc compiler is it even possible to do? – PastaWithGarlicOil Aug 16 '17 at 11:18
  • @PastaWithGarlicOil check if their linker is capable to do so. It require linker to be capable of the link time optimisations. You need to check the documentation. did you check with the debugger or just the generated listing? If the latter it can be like this as information about potential link time inlining is in the object file and the function call is replaced by the function body during the link stage – 0___________ Aug 16 '17 at 11:31
  • @PeterJ i checked with the debugger – PastaWithGarlicOil Aug 16 '17 at 11:36
  • @PeterJ - Link time code generation is not supported for .asm files, but would normally use compiler intrinsics for any "interesting" machine instructions. Inline functions as code obfuscation was apparently not considered by Microsoft. :-) – Bo Persson Aug 16 '17 at 11:39
  • @PeterJ thanks i will look trough all linker directives, maybe there are some link time optimisations – PastaWithGarlicOil Aug 16 '17 at 11:40
  • @BoPersson so sad, Do you know, is it possible to just insert machine codes inside the function body at compile time? something like `_asm _emit`? – PastaWithGarlicOil Aug 16 '17 at 11:43
  • @Pasta - No, there really isn't any use for that, except for your attempt to make the code harder to read. All "real" use of inline assembly can be replaced with compiler intrinsics for useful instructions that the compiler might not use itself. There are hundreds, if not thousands, such instructions built into the compiler. https://learn.microsoft.com/cpp/intrinsics/x64-amd64-intrinsics-list – Bo Persson Aug 17 '17 at 11:34

0 Answers0