Memory Manager Redesign

[KGergo88]

Preconditions

• [x] We need to have functional tests for the test_project with Emma (see #3) before we change anything in order to be sure that the same values will come out from Emma after the changes

Postconditions

• [x] Unused imports needs to be removed
• [x] Integrate individual mapfile paths feature (issue #16 )
• [x] Document added with description how to add support for new compilers
  • [x] Evaluate where this would belong: separate document or in the contributions document? It was described in the doc/contribution.md
  • Add description to the doc/contribution.md about the compiler specific configuration design hints
  • [x] Add instructions to the contribution.md which documents and tests need to be added for the new compiler supprt
  • [x] Make it clear in the doc/readme.md which parts of the configuration is general and which is compiler specific
  • [x] Move the current specific parts into a GHS configuration chapter

Branch

• [x] The issue needs to be developed on the ISSUE_#5_MemoryManagerRedesign branch

Necessary configuration changes:

• [x] The globalConfig.json needs to contain a new key for every configId that specifies the used compiler. This is needed to be able to instantiate the compiler dependent Compiler and MapfileProcessor objects. This can not be a command line argument because it is possible to have configurations where the configIds have different compilers.

Motivation

• The MemoryManager class is:
  • simply too big to develop unit test​s for it
  • way too complex to integrate the future changes, like the gcc compiler into it
  • the compiler specific parts are not separated from the generic ones

New design

UML Diagram

• https://www.lucidchart.com/invitations/accept/2f7d235c-d3c8-4e53-aa36-6cb66306b585

Description of the new classes (a slightly different design was implemented, see UML Diagram)

• MemoryManager:
  • Organizing the process of creating CVS files from the configuration files and the mapfiles
  • It executes each task trough registered objects to be independent from the implementation details of these
  • It contains as minimal code as possible, it only serves the purpose of organization and providing it´s components with data
  • List of registered objects:
    • A specialized configuration object
    • A specialized mapfile processor object
    • MemoryMap

• Configuration

  • A superclass of compiler specific configuration processors
  • Processes the generic parts of the configuration
  • Provides an interface to use the processed information
  • Tasks that are realized in the superclass:
    • Processing the global_config.json
    • Processing the addressSpaces_*.json
    • Processing the "mapfile" object in the patterns_*.json
    • Processing the categoriesObjects.json
    • Processing the categoriesObjectsKeywords.json
    • Processing the categoriesSections.json
    • Processing the categoriesSectionsKeywords.json
    • List of functions: readGlobalConfigJson() addFilesPerConfigID() addMapfilesToGlobalConfig() __validateConfigIDs()
      removeUnmatchedFromCategoriesJson() createCategoriesJson()
  • Tasks that are realized in the subclasses:
    • Processing the rest of the patterns_*.json (the "mapfile" object is processed in the superclass)
    • Processing of virtualSections_*.json (because we do not know the VAS-es are with other compilers)
    • List of functions: checkMonolithSections() addTabularisedMonoliths() addMonolithsToGlobalConfig()

• MapfileProcessor

  • Superclass of compiler specific mapfile processors
  • Tasks that are realized in the superclass:
    • Doing generic tasks during the mapfile content processing
    • Produces a list of ObjectEntry and a list of SectionEntry objects
    • List of functions: evalMemRegion() addMemEntry() categoriseByKeyword() searchCategoriesJson() evalCategory() evalRegexPattern()
  • Tasks that are realized in the subclasses:
    • Doing specific tasks during the mapfile content processing
    • List of functions: __translateAddress() importData()

• MemoryMap

  • Receives a list of ObjectEntry objects and a list of SectionEntry objects
  • Resolves the duplication, containment and overlap of these lists
  • After the resolving it creates the ObjectsInSections MemEntry object list
  • From these three lists it creates the ObjectSummary, the ImageSummary and the ObjectsInSections CVS tables
  • Writes the CVS tables to the HDD
  • List of fuctions: writeSummary() createMemStatsFilepath() consumerCollectionToCSV() resolveDuplicateContainmentOverlap() calculateObjectsInSections() memoryMapToCSV()

[holzkohlengrill]

Regarding the flags for the compiler options I would comply with the names defined here: https://cmake.org/cmake/help/git-master/variable/CMAKE_LANG_COMPILER_ID.html

Please add this also in the developer documentation ("technical details") that for future implementations those names should be used.

[holzkohlengrill]

Please update version to 3.0

[holzkohlengrill]

New TODO: Include #16 into redesign.