Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>If you look at the assembly produced from compiled C functions, you will see every function body wrapped by</p> <pre><code>pushq %rbp movq %rsp, %rbp ; body leave ret </code></pre> <p><a href="http://en.wikipedia.org/wiki/X86_instruction_listings" rel="nofollow noreferrer">http://en.wikipedia.org/wiki/X86_instruction_listings</a> lists the <code>leave</code> instruction as an 80186 equivalent of (in AT&amp;T syntax)</p> <pre><code>movq %rbp, %rsp popq %rpb </code></pre> <p>So <code>leave</code> is just the inverse of the first two lines: save off the caller's stack frame and create our own stack frame, then unwind at the end.</p> <p>The closing <code>ret</code> is the inverse of the <code>call</code> that got us here, and <a href="http://www.unixwiz.net/techtips/win32-callconv-asm.html" rel="nofollow noreferrer">http://www.unixwiz.net/techtips/win32-callconv-asm.html</a> shows the hidden push and pop of the instruction pointer register that occurs during these paired instructions.</p> <p>The reason the void function pointer call doesn't work by itself, because of this assembly created for function <code>wrapfun</code> by the compiler. What we need to do is create the wrapper in such a way that it can hand the stack frame set up for it by the caller directly to the call of <code>fun</code>, without its own stack frame getting in the way. In other words, observe the C calling convention and violate it at the same time.</p> <p>Consider a C prototype</p> <pre><code>int wrapfun(int x, int y); </code></pre> <p>paired with an assembly implementation (AT&amp;T x86_64)</p> <pre><code> .file "wrapfun.s" .globl wrapfun .type wrapfun, @function wrapfun: call funptr jmp *%rax .size wrapfun, .-wrapfun </code></pre> <p>Basically, we skip the typical stack pointer and base pointer manipulation, because we want <code>fun</code>'s stack to look exactly like my stack. The call to <code>funptr</code> will create his own stack space and save his result into register <code>RAX</code>. Because we've got no stack space of our own, and because our caller's <code>IP</code> is sitting nicely at the top of the stack, we can simply do an unconditional jump to the wrapped function, and let his <code>ret</code> jump all the way back. In this manner, once the function pointer is invoked, he will see the stack as it was set up by his caller.</p> <p>If we need to use local variables, pass parameters to <code>funptr</code>, etc, we can always set up our stack, then tear it down prior to the call:</p> <pre><code>wrapfun: pushq %rbp movl %rsp, %rbp ; set up my stack call funptr leave ; tear down my stack jmp *%rax </code></pre> <p>Alternatively, we could embed this logic into inline assembly, taking advantage of our knowledge of what the compiler will do before and after:</p> <pre><code>void wrapfun() { void* p = funptr(); __asm__( "movq -8(%rbp), %rax\n\t" "leave\n\t" "popq %rbx\n\t" "call *%rax\n\t" "pushq %rbx\n\t" "pushq %ebp\n\t" // repeat initial function setup "movq %rsp, %rbp" // so it can be torn down correctly ); } </code></pre> <p>This approach has the advantage of easier declaration of C local variables prior to the magic. The last local variable declared will be at RBP-sizeof(var), and we save it in RAX prior to tearing down the stack. Another possible benefit is the opportunity to use the C preprocessesor to, for example, inline 32-bit or 64-bit assembly without requiring separate source files.</p> <p><strong>EDIT:</strong> The disadvantage is now the requirement to save the IP into a register limits the application portability by requiring <code>RBX</code> to not be used by the caller.</p> <p>In short, the answer is yes. It is definitely possible to wrap a function without knowing its signature, if you are willing to get your hands a little dirty. No promises as to portability ;).</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload