[lldb-dev] Redefining functions

[Greg Clayton]

On Jul 18, 2011, at 1:32 PM, Filipe Cabecinhas wrote:

> Hi,
> 
> I'm trying to create an LLDB command that sets an internal breakpoint for a function, and then executes some code, but I'm having come difficulties...
> 
> I've seen the expression command, which does something close to what I want to do after the breakpoint, but I have some doubts. I want the code to be able to return from the function where it's called, but the "target->EvaluateExpression" doesn't let the code return from it (while I would like to execute code with something like "if (condition) return NULL; more code…"). Is there a way to compile arbitrary code (with return statements) and execute it?

Not currently.

> 
> Is there a way to create something like an anonymous function (with certain parameters), and have it compiled and linked, while looking up global variables?

Current expressions can do the lookups, but as you already know they don't live beyong the first invocation.

> ClangUtilityFunction doesn't look up any variables, and I can't seem to find a way to look up global variables without a Frame object.

For globals you shouldn't need the frame. If the globals are in your symbol table and are external you might be able to use dlsym().

> Is there a way to know a function (or method)'s address from its prototype?

A normal fuction that was compiled into your code or an expression function?

> 
> My final purpose is to be able to redefine functions on-the-fly (with caveats for inlined functions, etc). The only way I saw that could work was creating a (similar) function and making the other function a trampoline (either using breakpoints, or writing a jmp expression at its address)… Did I miss another easier way?

We do want the ability to just compile up something in an LLDB command but we don't have that yet. You currently can do this via python if you really want to by making a source file, invoking the compiler on it, and then making a dylib. You can then use the "process load" command to load the shared library:

(lldb) process load foo.so

So if you have your python code do the global variable lookups and create the source code, you could hack something together.

When/if you are ready to try and take over the function, you can look for any "Trampoline" symbols. For a simple a.out program on darwin we see:

(lldb) file ~/Documents/src/args/a.out
Current executable set to '~/Documents/src/args/a.out' (i386).
(lldb) image dump symtab a.out 
Symtab, file = /Volumes/work/gclayton/Documents/src/args/a.out, num_symbols = 18:
               Debug symbol
               |Synthetic symbol
               ||Externally Visible
               |||
Index   UserID DSX Type         File Address/Value Load Address       Size               Flags      Name
------- ------ --- ------------ ------------------ ------------------ ------------------ ---------- ----------------------------------
....
[   10]     16     Trampoline   0x0000000000001e76                    0x0000000000000006 0x00010100 __stack_chk_fail
...
[   12]     18     Trampoline   0x0000000000001e7c                    0x0000000000000006 0x00010100 exit
[   13]     19     Trampoline   0x0000000000001e82                    0x0000000000000006 0x00010100 getcwd
[   14]     20     Trampoline   0x0000000000001e88                    0x0000000000000006 0x00010100 perror
[   15]     21     Trampoline   0x0000000000001e8e                    0x0000000000000006 0x00010100 printf
[   16]     22     Trampoline   0x0000000000001e94                    0x0000000000000006 0x00010100 puts

On MacOSX, you could then easily patch the trampoline code to call your own function for say "printf" by modifying the function address in the PLT entry.