[lldb-dev] Redefining functions

Jason Molenda jmolenda at apple.com
Mon Jul 18 18:28:01 PDT 2011


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

> 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?

For what it's worth, we implemented a feature like this in the Apple fork of gdb, called "Fix and Continue".  Sun's dbx has the feature as well (also called F&C there).  MS Visual Studio and HP's wdb also had something similar.  All of these allow you to modify source code in the middle of a debug session, compile it into a loadable bundle, and have the debugger patch all references to the newly loaded code.

With C code, it's difficult to implement but possible.  With C++ things get much more complicated.  On our system, we had some assistance from the Objective-C runtime and compiler to make things work .. but it's very hard for users to understand what is legal and what is illegal (or ill-advised) to change in the middle of execution.  It makes for great demos, and for certain types of changes it can work well.  But it's so easy to mess up that in practice I don't think it's a good feature to support with these languages.

There's a feature in the Apple debugger GUI (Xcode's debugger interface) where the about-to-be-executed source line has an arrow pointing to it in the source code window.  The user can drag this arrow back a few lines, or forward a few lines, to change which source line will be executed when execution resumes.  It's a cool feature but you really need to understand how the compiler generates code and what assumptions about scopes and variable lifetimes it is using -- skip over a ctor and execute some code and there will all kinds of problems.  I think this is in the same class as F&C - much riskier than regular developers appreciate, and confusing when it fails.

My two cents,

J



More information about the lldb-dev mailing list