Greetings! As some of you may recall, the bfd-based linker has a >1Mb overhead on the final image size. As we know, this is a waste we can likely live with, but for other reasons, I've managed to implement a replacement where the bfd memory pertaining to the parent image is freed and the C symbol addresses are hashed instead as values of lisp symbols interned in a special package "LINK". This takes out about 500k of the waste, uses significantly faster relocatable memory, but perhaps most importantly, brings this information forward to the lisp level where it may be of future use. It would still be more efficient memory wise to use a simple hash table of strings and long integers as opposed to symbols and fixnums, but then we'd loose lisp access. Feedback/opinions are most welcome. The primary benefit of lisp access to this info of which I can conceive at present is in use for profiling, where it would be quite desirable to be able to generate a gprof-like ranked call graph without having to make all images with compiler::link. I'm not sure this is worth it, though.
============================================================================= (let ((i 0)) (do-symbols (s 'link) (format t "~S ~S~%" (symbol-name s) (when (boundp s) (symbol-value s))) (incf i)) i) "in_list_flag" 138056556 "__gmpz_divexact_ui" 134523884 "bfd_open_file" 134786064 "add_history" 134524700 "init_gcl_cmpmap" 135974320 ... 2773 ============================================================================= Take care, Camm Maguire [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
