[Vm-dev] VM Maker: VMMaker.oscog-eem.293.mcz

[commits at source.squeak.org]

Eliot Miranda uploaded a new version of VMMaker to project VM Maker:
http://source.squeak.org/VMMaker/VMMaker.oscog-eem.293.mcz

==================== Summary ====================

Name: VMMaker.oscog-eem.293
Author: eem
Time: 5 June 2013, 12:11:06.561 pm
UUID: 1aa1e0a0-8883-4493-b0eb-226057aaabe3
Ancestors: VMMaker.oscog-eem.292

tweak VMProfileLinuxSupportPlugin's class comment

=============== Diff against VMMaker.oscog-eem.292 ===============

Item was changed:
  InterpreterPlugin subclass: #VMProfileLinuxSupportPlugin
  	instanceVariableNames: 'numModules primErr'
  	classVariableNames: ''
  	poolDictionaries: ''
  	category: 'VMMaker-Plugins'!
  
+ !VMProfileLinuxSupportPlugin commentStamp: 'eem 6/5/2013 12:10' prior: 0!
- !VMProfileLinuxSupportPlugin commentStamp: 'eem 6/4/2013 15:31' prior: 0!
  This class provides support for the VMProfiler on Linux (at least linux versions that provide dl_iterate_phdr).  This support is for reading symbols from the executable.  We can use the OS's nm command to list symbols in the VM executable and loaded libraries.  To do this we need to know what libraries are loaded, not simply which libraries are linked against, since some libraries are loaded dynamically, and for each loaded library what the vm address relocation, if any, is for the loaded library.  
  
+ Further, we need to know the actual addresses in memory of symbols in the program and in memory.  Since the OS may be using address randomization we cannot assume that the addresses answered by nm for symbols in the program and/or libraries match the addresses of the same symbols in memory.  Instead we must correlate.  dlsym can be used to look up symbols in loaded dynamic load libraries, but it does _not_ answer the addresses of symbols in the main program.  Back in the day nlist could be used to do this, but it is no more.  Instead this module contains a reference to interpret and answers its address ia a primitive (alas this means the plugin must be internal, but it's extremely small, and the VM links against libdl.so anyway).  Any address space shift will therefore be the difference between nm's output for interpret and the primitive's value.  We can similarly compute the address shift for libraries by using dlsym to lookup a symbol in a library and comparing it to nm's output for the library.
- Further, we need to know the actual addresses in memory of symbols in the program and in memory.  Since the OS may be using address randomization we cannot assume that the addresses answered by nm for symbols in the program and/or libraries match the addresses of the same symbols in memory.  Instead we must correlate.  dlsym can be used to look up symbols in loaded dynamic load libraries, but it does _not_ answer the addresses of symbols in the main program.  Back in the day nlist could be used to do this, but it is no more.  Instead this module contains a reference to interpret and answers its address ia a primitive.  Any address space shift will therefore be the difference between nm's output for interpret and the primitive's value.  We can similarly compute the address shift for libraries by using dlsym to lookup a symbol in a library and comparing it to nm's output for the library.
  
  
  The primitive primitiveExecutableModules returns the names of the executable and the loaded libraries.!