One Article Review
| Source |  MSReverse |
|---|---|
| Identifiant | 2555906 |
| Date de publication | 2020-05-08 01:22:33 (vue: 2021-03-29 15:05:20) |
| Titre | A Compiler Optimization involving Speculative Execution of Function Pointers |
| Texte | Today I discovered a neat optimization that I'd only heard about in graduate school, but had never seen in a real binary. Although the code below involves virtual functions in C++, the same technique would work for ordinary function pointers in C. A few other optimizations are referenced in the explanation below; all of them can be found in my presentation, "Compiler Optimizations for Reverse Engineers", which is the course sample for one of my reverse engineering training classes.The optimization has to do with increasing speculative execution performance for function pointers that nearly always target one particular destination. Note that this is in contrast to the compiler optimization known as "devirtualization", which is when a compiler can prove that a particular function pointer invocation must always target one particular location, and turns the indirect call into a direct one. The optimization described in this entry differs in that the function pointer might nearly always point to one location, but might occasionally point elsewhere. (These estimates of runtime behavior could be derived through profiling, for example.) The following is a snippet of code that comes from Microsoft's Active Template Library (ATL). More specifically, the smart pointer known as CComPtr, held in atlcomcli.h. Here is the code; modest, and unassuming: template class CComPtr { T* p; // Release the interface and set to NULL void Release() throw() { T* pTemp = p; if (pTemp) { p = NULL; pTemp->Release(); } } }Being a template class library, the programmer is free to create their own classes based on CComPtr by specifying any class type for the template typename parameter T. Or rather, any class type that has a method named "Release" with signature "void Release()", as that function is invoked by the if-body in the code above. In this scenario, Release is a virtual function - that is to say, objects of type T contain a function pointer pointing to the implementation of a function called “void Release()”.In the code below, T is specialized by (i.e., replaced with) a scary-looking ATL type name called ATL::CComObject. So in particular, here is the compiled version of CComPtr::Release, whose generic C++ code was shown above. The first four lines aren't interesting: .text:18005121B mov rcx, [rcx] ; T* pTemp = p; .text:18005121E test rcx, rcx ; if (pTemp) { .text:180051221 jz short return ; [if not taken, return] .text:180051223 and qword ptr [rax], 0 ; p = NULL;The final line, the call to pTemp->Release, has a longer compiled body than one might expect. A line-by-line explanation follows below. .text:180051227 lea rdx, offset ATL::CComObject::Release .text:18005122E mov rax, [rcx] .text:180051231 mov rax, [rax+10h] ; rax now contains the pTemp->Release pointer .text:180051235 cmp rax, rdx ; did rax match the fixed location in rdx above? .text:180051238 jnz short no_match .text:18005123A call ATL::CComObject::Release .text:18005123F .text:18005123F return: .text:18005123F add rsp, 28h .text:180051243 retn .text:180051244 .text:180051244 no_match: .text:180051244 add rsp, 28h .text:180051248 jmp raxTo explain the code above: Line #-27: move the offset some specific function into rdx.Line #-2E through -31: rax now contains the pTemp->Release function pointer.Line #-35 through -38: Compare rax and rdx. If equal, don't take the jump.Line #- |
| Envoyé | Oui |
| Condensat | &atl::ccomobject::release 27: 28h 31: 38: 43: 48: >release about above above: active actually add address after algorithm all allow also although always another any anyway anywhere are aren arranges aspect assumes atl atl::ccomobject atl::ccomobject::release atlcomcli based because been before begin behavior being below below; better binary body branch but c++ call called calls can ccomptr ccomptr>::release class classes clearly cmp code code: code; comes compare compares comparison compiled compiler contain contains contrast could course create data derived described destination destinations destroying determine devirtualization did differs direct direction directly discovered does doesn don down elimination elsewhere encourages end engineering engineers entry equal estimates example execute executing execution expect explain explanation explicit fact final first fixed following follows forward found four frame free from function functions generic get going graduate had happening has have heard heavily held hence here however implementation important increasing indirect insert instead interesting: interface introduced invocation invoke invoked involves involving it: jmp jnz jump jumps know known lea let library line lines location longer looking match match: matches method microsoft might modest more moreover mov move moved must name named nearly neat needs never not note notice now null null; null;the objects occasionally offset one only optimization optimizations optimizing ordinary original other otherwise own parameter part particular parts path pentium performance performing point pointer pointers pointing points precisely prediction present presentation probable processor profiling programmer prove ptemp ptr qword rather rax rax+10h raxto rcx rdx real reasonable referenced reflecting regardless release replaced result retn return return: reverse rsp runtime same sample say scary scenario school see seem seen set short shown side signature since smart snippet some specialized specific specifically specifying speculative speculatively stack start static success sufficient; superfluous tail take taken target technically technique template test text:18005121b text:18005121e text:180051221 text:180051223 text:180051227 text:18005122e text:180051231 text:180051235 text:180051238 text:18005123a text:18005123f text:180051243 text:180051244 text:180051248 than them then there therefore these thing through throw today training turns type typename unassuming: usually version virtual visual void weird what when where which whose why will won words work worse would “void |
| Tags | |
| Stories | |
| Notes | |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.