91 lines
4.4 KiB
HTML
91 lines
4.4 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
|
|
<HTML VERSION="2.0">
|
|
<HEAD>
|
|
<!-- WEBMAGIC VERSION NUMBER="2.0.1" -->
|
|
<!-- WEBMAGIC TRANSLATION NAME="ServerRoot" SRC="/var/www/htdocs/" DST="/" -->
|
|
<!-- WEBMAGIC TRANSLATION NAME="ProjectRoot" SRC="./" DST="" -->
|
|
<TITLE> Modular IDE: Loading and Symbol Resolution </TITLE>
|
|
</HEAD>
|
|
<BODY>
|
|
<P><A HREF="modular.html"><IMG SRC="/images/diags.gif" WIDTH="100" HEIGHT="75" BORDER="2" SGI_FULLPATH="/var/www/htdocs/images/diags.gif"> </A></P>
|
|
<H1>Modular IDE:Loading and Symbol Resolution </H1>
|
|
<HR>
|
|
<H3>Initial Core Loading </H3>
|
|
<OL>
|
|
<LI>Core IDE is loaded at a fixed address by the Prom.
|
|
<LI>Core Ide begins executing its script.
|
|
<LI>If Core IDE encounters a load command (either via its script or from the
|
|
user), it executes the module loading mechanism described below.
|
|
</OL>
|
|
<H3>Module Loading & Execution Mechanism</H3>
|
|
<OL>
|
|
<LI>If no other modules have been previously loaded by Core IDE, Core reads
|
|
its own symbol table (this is done only once before the first module is
|
|
loaded). This symbol table will later be used by Core IDE to resolve core
|
|
symbols in IDE modules.
|
|
<LI>The load command will only load a module if is a dynamic elf binary (i.e.
|
|
the module has been compiled -shared). If this criteria is not met, the
|
|
load will fail.
|
|
<LI>Now Core IDE begins loading the dynamic elf module binary. To be able to
|
|
do proper symbol resolution later, Core IDE needs to make sure that the
|
|
following elf program segments exist in the module:
|
|
<OL>
|
|
<LI><I>.MIPS.options</I> segment: contains the value of the GP (global pointer) of the module
|
|
<LI><I>.got</I> segment: contains the Global Offset Table (GOT). The GOT is used to resolve
|
|
symbols in the module that refer to Core symbols. Note that a module may
|
|
not have a GOT if it has no unresolved symbols.
|
|
<LI><I>.dynsym</I> segment: the dynamic symbol table. This symbol table is used by Core IDE
|
|
to find the module's undefined symbols (the dynamic symbol table uses offsets
|
|
into the dynamic string table for symbol string names).
|
|
<LI><I>.dynstr </I>segment: the dynamic string table. The string table contains the string
|
|
names of the module's symbols. This is used by Core IDE to do symbol look-up
|
|
in conjunction with the dynamic symbol table.
|
|
</OL>
|
|
<LI><A NAME="symbol_resolution">Now Core IDE uses the following symbol resolution mechanism</A>:
|
|
<OL>
|
|
<LI>Core IDE scans through the dynamic symbol table (.dynsym) of the module
|
|
looking for undefined symbols.
|
|
<LI>For each undefined symbol:
|
|
<OL>
|
|
<LI>Core IDE uses the module's dynamic string table (.dynstr) to get the symbol's
|
|
string name.
|
|
<LI>Core IDE tries to look up the unknown symbol's string in its own symbol
|
|
table.
|
|
<LI>If the symbol is found, Core places the symbol's core address into the symbol's
|
|
GOT (.got) entry of the module. Else an error is reported and the load fails
|
|
due to an unresolved symbol.
|
|
</OL>
|
|
</OL>
|
|
<LI>All symbols are now defined in the module.
|
|
<LI>Core IDE uses the .reginfo segment to read the module's GP value. This value
|
|
is needed by the initial module code so that it can inialize the $gp register.
|
|
This register is needed because all symbol references in the module use
|
|
the GOT table which in turn depend on $gp as a base register.
|
|
<LI>Core IDE uses the standard argv & environment passing mechanism of the Prom
|
|
as follows:
|
|
<OL>
|
|
<LI>argv[0] contains the path name of the module
|
|
<LI>argv[1] contains the module's GP value in ascii (no leading 0x or 0X).
|
|
<LI>the remaining argv strings which were passed to Core IDE from Prom are passed
|
|
to the module in argv[2], argv[3], ....
|
|
<LI>the environment strings which were passed to Core IDE from Prom, are copied
|
|
and passed to the module
|
|
</OL>
|
|
<LI><A NAME="start_module">Core IDE jumps to the module's start_module() assembly routine and begins
|
|
execution</A>.
|
|
<LI>Before any references can be made by the module, its $gp register must be
|
|
set so that references can go through the GOT. The very first thing that
|
|
start_module() does is convert the GP value string in argv[1] to a hex number
|
|
and store it in $gp. Once $gp is set, the module's stack can be initialized,
|
|
the original $gp is saved, the original stack is saved, and the C module_main()
|
|
function is called.
|
|
<LI>module_main() can now set variables in the Core to point to the module's
|
|
script and its list of module commands.
|
|
<LI>Finally, module_main() calls the Core main() function which starts the parser
|
|
on the module's script.
|
|
</OL>
|
|
<HR>
|
|
<ADDRESS><A HREF="http://gork/mail-form.html">stojanof@engr.sgi.com</A></ADDRESS>
|
|
</BODY>
|
|
</HTML>
|