1

I am using this code here :

include "windows.h"  
#include "stdio.h"
#include <conio.h>
#pragma comment(lib, "StubDLL.lib")
// StubDLL defines as __declspec(dllexport)  Add and Function

#include "StubDLL.h"

// just to try it with MS Function
__declspec(dllimport) HANDLE WINAPI GetCurrentProcess(void);

/*
this is done in StubDLL.h
extern "C"
{
    __declspec(dllimport) int Add(int a, int b);
    __declspec(dllimport) void Function(void);
}
*/
int main()
{
    Function();
    std::cout << Add(32, 58) << "\n";

    HANDLE test = GetCurrentProcess();

    printf("%d \n", test);

return 0;
}

now, according to: https://msdn.microsoft.com/en-us/library/aa271769(v=vs.60).aspx:

__declspec(dllimport) hints the compiler backend that the function called resides in an external DLL and therefore should not generate an indirect call (FF 15 ...) meaning no indirect calls to a trampoline...

when looking at the disassembly, Function(), Add(), and GetCurrentProcess() result in indirect far calls, which should not happen, as I explicitly give the compiler the hint not to emit an "FF15" but insted an "E8".

Apparently I am missing sth. here... Any hints ? ( project setting is VS 2015, Release build, no incremantal linking, size over speed, optimize for size)

n80fr1n60
  • 701
  • 1
  • 6
  • 12
  • The definition for `GetCurrentProcess` will have already been seen because you included `windows.h`. The 2nd definition will just confuse the compiler. – Richard Critten Sep 04 '17 at 12:13
  • "therefore should not generate an indirect call (FF 15 ...)" documentation you are linking does not state that. It actually states the opposite: "If func1 exists in another DLL, the linker can't resolve this directly because it has no way of knowing what the address of func1 is." – user7860670 Sep 04 '17 at 12:17
  • The article states exactly the opposite. When the compiler knows the function is in the DLL, it generates an *indirect* call through an entry in the import table. When the compiler doesn't know that, it generates a *direct* call, hoping the linker would fill in the address. But the linker cannot, and is then forced to generate a thunk that performs an indirect jump (through that same import table entry). The call site might be smaller, but every call involves an extra hop. – Igor Tandetnik Sep 04 '17 at 12:36
  • ok, GetProcess makes sense... when using __declspec(dllimport) void foobar(void);it is a hint to the compiler that it should not generate a far call "ff 15" leading to no thunk and no jmp instruction – n80fr1n60 Sep 04 '17 at 12:51
  • (see https://blogs.msdn.microsoft.com/oldnewthing/20060724-00/?p=30403/) If a function is declared with the dllimport declaration specifier, this instructs the Visual Studio C/C++ compiler that the function in question is an imported function rather than a normal function with external linkage.With this additional information, the compiler generates slightly different code when it needs to reference an imported function, since the compiler is aware of the special way imported functions are implemented. and it generates an e8 call and not an FF 15 call – n80fr1n60 Sep 04 '17 at 12:57

0 Answers0