Re: Howdy from Apple; Fix and Continue implemented Yet Again

[Jason Molenda <jason-swarelist at molenda dot com>]

On Sat, Jun 28, 2003 at 09:54:22AM -0400, Kris Warkentin wrote:
> That's pretty interesting.  Does it require any special os support in the
> debug interface or is it all done with dlopen/dlclose, etc.?  Other than
> compiling your app PIC, does it require any other special compiler features?

There aren't a lot of additional requirements.  The main app doesn't
have to be PIC, but the Fixed file does.  Mike Stump added two gcc
options to support Fix and Continue:  the first pads the prologues
of every function with a few NOP instructions, the second creates
indirect references for all file-static data.  We also had to modify
the Objective C runtime to not register the duplicate classes in
the Fixed file, and a new option to our dlopen equivalent,
NSLinkModule.

The NOPs are added so that we're guaranteed to have room for the
5-instruction long trampoline sequence (four insns plus an illegal
op code so I can reliably detect the sequence).  F&C is only used
on unoptimized code[1] but it's possible for a function to be too
small on a PowerPC if it has no body or arguemnts. 

[1] F&C could be used on optimized code as long as you never try to
update the PC from the middle of an old function to the middle of a
new function.  If you keep running the old version of a function,
or you don't ever fix while a function is on the stack, optimized
code should work correctly.


The file-static indirection is a bit trickier.  Normally references
to global data are made indirectly, with the static link editor or
dynamic linker updating the references at link/runtime.  But when
you refer to static data in your file, or global data that is
allocated in that file, the indirection is not necessary.  So a
simplistic approach to F&C (the one H-P took) will have a separate
copy of each file static/global variable for each time you Fix a
file.  (H-P does copy the values from the globals at Fix time)
Instead, we changed our compiler and assembler to force all of
these file-static references though a table of indirections.  The
table is an array of addresses, one for each static, containing the
offset of the variable in the DATA section.  gdb tries to match
these up to identify which (struct symbol) each entry is referring to,
finds the original structure, and changes the indirection table to
point to the original one.

In the dynamic linker, we added a feature to suppress static
initializers in Fixed solibs.  We don't export the function names
in the Fixed solib (aka don't add RTLD_GLOBAL to the dlopen() call
in Linux-speek :), and we added a
NSLINKMODULE_OPTION_DONT_CALL_MOD_INIT_ROUTINES option to NSLinkModule()
for this.  The file static data will be redirected to the
already-initialized data so there's no need to run the initializers,
and doing so could have side effects to the program, so we just
avoid the whole issue by not running those.


The important thing for our customers is that F&C is ready to be
used at all times when they're doing "development style" builds.
We build -g -O0 and add in the compiler flag to pad prologues 
automatically.  Then, half-way through debugging, they realize they
want to use F&C and it's ready to go.

The H-P implementation does use one other feature from the compiler.
They rebuild the source file from within gdb, so they require the
compiler to put the entire compiler command line option in the .o file.

J