Calling C + + functions in Lldb debugging

In Lldb debugging, it is not surprising to call the OC object, because Msgsend is derived from a prototype, the OC object's methods are bound by the runtime, and the binding information is in Objc_class. As long as in debugging [receiver Sel], the LLDB automatically completes the entire process of the Imp method that is routed by the SEL via Msgsend to receiver and executes. However, it is not so convenient to invoke C + + functions, although the link symbols for C + + functions (including member functions and non-member functions) have detailed information about the function prototype, but do not include the definition of the class and the definition of the namespace, even if lldb translates such a symbol (symbol) Quartzcore ' CA :: render::layer::show (unsigned int, unsigned int), which in our view is a function prototype, but the debugger does not think so, we have no way to directly use the above symbol, unless we have other people publish the module's symbol file, This is not possible. For example, when you call this show method, you will think of specifying the object as ca::render::layer* and then referencing the Show method plus parameters. In fact, the LLDB debugger will complain that the CA name or structure is not defined, Ca::render is not defined, ca::render::layer not defined, the above that clearly has we think that the information complete symbol can not be so easily used by you.

What to do, I would like to use this module to design their own print object information method to understand and deepen the reverse useful information, we have to try to build the call stack and modify the program counter address to simulate the function of the call. In the WinDbg can use this method, LLDB should also have no problem, I think so.

First I reverse its code, know that this class does not have multiple inheritance, as long as the object is broken one of the member methods, before it does not operate the stack, the use of this pointer (even if it is multi-inheritance, then this pointer has been in the entrance before the correct adaptation), in the end choose that a function good? There are two member functions that are basically called on the object, that is, constructs and destructors, the objects in the construction are not available, then it is selected before the destruction.

Breakpoints in the Ca::render::layer::~layer () method,

After the breakpoint is triggered, build the call stack, or use the stack to save the register, the operation is as follows

-0x20 (%RSP) <--%rip; Return address, Analog call command

-0x18 (%RSP) <--%RDX; Analog Push%RDX

-0x10 (%RSP) <--%rsi; Analog Push%rsi

-0x8 (%RSP) <--%rdi; Analog Push%rdi

%RSP <--%rsp-0x20; To point the top of the stack to the built call stack

%rip <--&ca::render::layer::show; Simulating jmp

Then, step into is executed, and the interrupted thread executes the Ca::render::layer::show method, using the this pointer at the entrance of the Ca::render::layer::~layer () method.

I will Ca::render::layer::~layer () the entry address, write to jump front stack top, the thread returned from Ca::render::layer::show will again enter my breakpoint method, then will%RDI,%RSI,%RDX restore,% RSP Restore,%RSP <--%rsp + 0x18, the thread is already returning the address stack when the show function Retq. Let the thread continue to run on the original track.

The big to call frame is settled.

Can this be successful? Do not worry first, I first to confirm that the change%rip jump is not valid. Do not try not to know, a try to frighten a jump. After modifying%rip, type S instruction to lldb console execution, lldb console loses interactive control not returned, thread is not executed. Had to use Xcode debugging single-step shortcut F6,xcode Single Step F6 was executed, LLDB console again return to the interactive state, the thread into the Ca::render::layer::show function of the second instruction, that is, the debugger executed two step into instruction (the first is the S-command of the LLDB console, and the second is Xcode's single-step F6). The step is then out or called finish, and the function returns to the next instruction at the call to Ca::render::layer::~layer (). Run as expected, as I did not build to the call stack, the this pointer is also used correctly. I do the behavior, let the original to execute Ca::render::layer::~layer () jump to the Ca::render::layer::show, natural ~layer () is ignored. The Member method to be noted here is the caller balance stack by default, the destructor has no parameters, the return is naturally without the balance stack, although ca::render::layer::show has two parameters, but ca::render::layer::show himself is not going to balance the stack, So the stack balance is fine.

However, the problem also comes out, directly modify the%RIP,LLDB console will not work properly. Out of strict attitude, I tried, I again in the ~layer () at the entrance did another%rip modification, but the address of the jump is at the end of the ~layer (), that is, the function jumps, the result does not affect the work of the LLDB console. But jumping across functions is less than desirable.

In any case, the plan continues, this time adding the build call stack. This time again, when I finished modifying the%RSP, the console again loses its interaction when the LLDB console type a directive modification%rip points to ca::render::layer::show. Or the method above uses Xcode's F6 one step at a time, the console can interact again and the thread enters the Ca::render::layer::show portal. But then there's a problem with running, not in the balance of the call stack I'm building, but instead of ca::render::layer::show the stack operation with other functions called in the body. From the above is the situation to directly modify the%RSP or%rip, the debugger is running a problem, and in the Python script, with the LLDB instructions to access the register operation is not advisable, for reasons please see my last write to step on the pit.

Because the method of building the call stack is inappropriate, but I would like to use the module's own function method, because it is the emulator, with the x64 processor, the calling convention takes precedence of the Register, C + + member function call parameter Convention and non-member function call parameter convention can look like, (parameter convention is the same order, However, the 32-bit processor compiles the first parameter is a stack, the this pointer uses the register, the two functions are different). Then went ahead, the member function is flattened to a non-member function, while LLDB supports the custom function type, (in VC or WinDbg, it is not possible to define a function type in the debugger to convert the type of the ingress address). You can then convert the image address of the ca::render::layer::show (unsigned int, unsigned int) to a void (*) (void*, int, int) type in Ca::render: Layer any member function, through the LLDB expression or printing and other instructions to call the Ca::render::layer::show method, the use of Apple's own module to print out the function of the message. This method can print out the information of the created object in the Python script using no problem, as a breakpoint command. Again, do not use Handlecommand in the Python script to access the register, the question is discussed in the previous article, interested please see.

Finally, ca::render::layer::show printed what information, output to where, please see the next introduction.

Calling C + + functions in Lldb debugging