GC API: What can change for precise scanning?

[dsimcha]

Now that the compiler infrastructure has been implemented, I've 
gotten busy figuring out how to make D's default GC precise.  As 
a first attempt, I think I'm going to adapt my original solution 
from http://d.puremagic.com/issues/show_bug.cgi?id=3463 since 
it's simple and it works except that there previously was no 
clean way to get the offset info into the GC.  As Walter pointed 
out in another thread, the GCInfo template is allowed to 
instantiate to data instead of a function.  IMHO unless/until 
major architectural changes to the GC are made that require a 
function pointer, there's no point in adding this indirection.

I started working on this and I ran into a roadblock.  I need to 
know what parts of the GC API are allowed to change, and discuss 
how to abstract away the implementation of it from the GC API.  I 
assume the stuff in core.memory needs to stay mostly the same, 
though I guess we would need to add a setType() function that 
takes a pointer into a block of memory and a TypeInfo object and 
changes how the GC interprets the bits in the block.

In gc.d, we define a bunch of extern(C) functions and the proxy 
thing.  Since we've given up on the idea of swapping precise GCs 
at link time, can I just rip out all this unnecesary indirection? 
  If not, is it ok to change some of these signatures?  I 
definitely want to avoid allocating (requiring the GC lock) and 
then calling a function to set the type (requiring another lock 
acquisition) so the signature of malloc(), etc. needs to change 
somewhere.

More generally, what is the intended way to get GCInfo pointers 
from TypeInfo into the guts of the GC where they can be acted on?