Performance:
    + create a small test library
    + find some genuinely weak / duplicate symbols in OO.o ...
    + add annotation etc. to that
    + checkout vtable instantation etc.


We are still doing too much work with symbol lookup
    + most of it highly avoidable.

    + ~95% is relocation processing ...
	+ fn relocations ...
    + populating vtable:
	+ looking up global / weak symbols [ why ? ]
	+ [ can they not be -Bsymbolic or something ? ]
	+ if 'dllexport' or the visibility attribute are 
	  used - we should/could hide local vtable
	  lookup bits ?
	+ we want the symbols to be 'protected' so they
	  are exported - by are resolved internally to
	  symbol-freea relocations
	+ The whole thing is crazy:
	    + we need only 1 'get-vtable' method per class ...
	+ Mark all 'virtual' methods of (SPECIFIED && DEFAULT)
	  linkage as 'protected' - ditto for generated thunks (?)
    + Understand the weak symbol issue [!?]
	+ add a throw/catch ...
	  fprintf (file, " %c%c%c%c%c%c%c",
	    ((type & BSF_LOCAL)
	    ? (type & BSF_GLOBAL) ? '!' : 'l'
	    : (type & BSF_GLOBAL) ? 'g' : ' '),
	   (type & BSF_WEAK) ? 'w' : ' ',
	   (type & BSF_CONSTRUCTOR) ? 'C' : ' ',
	   (type & BSF_WARNING) ? 'W' : ' ',
	   (type & BSF_INDIRECT) ? 'I' : ' ',
	   (type & BSF_DEBUGGING) ? 'd' : (type & BSF_DYNAMIC) ? 'D' : ' ',
	   ((type & BSF_FUNCTION)
	    ? 'F'
	    : ((type & BSF_FILE)
	       ? 'f'
	       : ((type & BSF_OBJECT) ? 'O' : ' '))));
	+ Weak symbols generated by:
	    + Templates ...
	    + Reference<Foo> type stuff ...
	    	    + non-virtual thunks
		    + type info (_ZTI)
		    + vtables (_ZTV)

    + [all to do with typeinfo behavior]
	+ re-read: http://www.nedprod.com/programs/gccvisibility.html
	  very carefully ...
    + Can we annotate the source with 'protected' for most methods ?

    + parent chaining ?
	+ doesn't go via vtable - but direct fn. call ...

    + Looks like we do all those bindings (relocs?)
	+ at dlopen time [!?] [ 10k relocations building vtables ? ]

    + need to check vs. gcc-4.x ...
	[ should be able to prune ... ]

Thoughts: (problem/soln/problem/...)
    + the deep / vcl OutputDevice -> Window -> Control -> ...
      vtable building issue is bad, bad news.
	+ why can't we get/copy the parent's vtable
	  with 'memcpy' ? instead of lots of lookups ?
    + can we parallelise the linker ?
	+ this problem is easily partitionable, surely ...
	    + [ no thread support in the linker ... ]

    + a 'thunk' fn does:
	+ adjust 'this' pointer & call method [ and MI feature ]

+ Things to check:
	+ anonymous namespaces ... - file path mangled in ?
	+ 