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.
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
