M3-SCoPE: Performance Modeling of Multi-Processor Embedded Systems for Fast Design Space Exploration - Multi-objective Design Space Exploration of Multiprocessor SoC Architectures - page 44

with a main function, it is not possible to declare them static . Otherwise, the
functions are hidden to the simulation kernel, and cannot be called.

Thus, a different solution avoiding these problems has been implemented. The first
two problems can be solved by forcing separate visibility scopes for functions and
variables on each component. The third problem requires modeling different memory
spaces. Defining different scopes is not enough to share variables among different
instances. Finally, the fourth problem can be overcome by providing an automatic
way of defining and loading different entry points with the same names.

2.5.3.1 Achieving Separate Visibility Scopes

Visibility scopes can be defined by creating namespaces or classes in the code. How-
ever, these solutions are limited and require recoding. The solution recommended
to implement the separate visibility scopes is to create shared libraries with all the
application SW codes required for each SW process to be simulated. Shared libraries
are libraries that are loaded by programs at run time. As the library is not copied into
the executable file, the executable size is minimized.
Dynamic libraries can be created using the following commands. In the code, two
source code files are compiled to create the corresponding object files, and then both
object files are integrated to create a shared library file:
gcc -fPIC -c filea.c #create object file
gcc -fPIC -c fileb.c #create object file
gcc -shared -o libmylib.so filea.o fileb.o
Shared libraries can be used in a static or a dynamic way. When used statically, at
link time, the linker searches through available libraries to find modules that resolve
undefined external symbols. Then, the linker makes a list with the libraries required
by the executable. When the program is loaded, start-up code finds those libraries
and maps them into the program's address space before the program starts. The
instruction used to create the executable is the following:

gcc main.c -o executable.x -L($Library_Path) -lmylib
When used dynamically, the library is unknown at link time. The library is se-
lected and opened during the execution of the program. As a consequence, the linker
command does not require a "-l" flag with the library names and paths.
To execute a program requiring shared libraries, the library must be in the library
path. When using a library created specifically for an example, it is expected not to
be in a standard library recognized directory. To add the library to the search list, the
environment variable LD_LIBRARY_PATH must be updated properly.
To create separate visibility scopes, shared libraries can be used in both ways.
The specific compiler options required for that purpose are related with the library
creation, not with its use. By default, a function of a shared library always calls the
symbol of the main program if it exists. To create separate scopes, the scope of all
library elements (functions and variables) must be defined as local to the library.