sergiotarxz/nuttx
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Rename gnu-nxflat.ld to gnu-nxflat-gotoff.ld; Add gnu-nxflat-pcrel.ld

Browse Source 
git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@5225 42af7a65-404d-4744-a932-0658087f49c3
This commit is contained in:
patacongo 2012-10-10 17:01:23 +00:00
parent 93fdd141d3
commit 281f35dd27
1 changed files with 22 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
Documentation/NuttXNxFlat.html
View File

@ -229,13 +229,16 @@
<li><b>Read-Only Data in RAM</b>
<ul>
<p>
Read-only data must reside in RAM.
With older GCC compilers (at least up to 4.3.3), read-only data must reside in RAM.
In code generated by GCC, all data references are indexed by the PIC<sup>2</sup> base register (that is usually R10 or <i>sl</i> for the ARM processors).
The includes read-only data (<code>.rodata</code>).
Embedded firmware developers normally like to keep <code>.rodata</code> in FLASH with the code sections.
But because all data is referenced with the PIC base register, all of that data must lie in RAM.
A NXFLAT change to work around this is under investigation<sup>3</sup>.
</p>
<p>
Newer GCC compilers (at least from 4.6.3), read-only data is no long GOT-relative, but is now accessed PC-relative. With PC relative addressing, read-only data <i>must</i> reside in the I-Space.
</p>
</ul>
</li>
<li><b>Globally Scoped Function Function Pointers</b>
@ -464,7 +467,7 @@ cat ../syscall/syscall.csv ../lib/lib.csv | sort >tmp.csv
<td><br></td>
<td><br></td>
<td>
<code>abc-nuttx-elf-ld -r -d -warn-common -T binfmt/libnxflat/gnu-nxflat.ld -no-check-sections -o $@ hello.o hello-thunk.o</code>
<code>abc-nuttx-elf-ld -r -d -warn-common -T binfmt/libnxflat/gnu-nxflat-gotoff.ld -no-check-sections -o $@ hello.o hello-thunk.o</code>
</td>
</tr>
<tr>
@ -507,7 +510,7 @@ cat ../syscall/syscall.csv ../lib/lib.csv | sort >tmp.csv
In this case, it will link together the module's object files (only <code>hello.o</code> here)
along with the assembled <i>thunk</i> file, <code>hello-thunk.o</code> to create the second relocatable object,
<code>hello.r2</code>.
The linker script, <code>gnu-nxflat.ld</code> is required at this point to correctly position the sections.
The linker script, <code>gnu-nxflat-gotoff.ld</code> is required at this point to correctly position the sections.
This linker script produces two segments:
An <i>I-Space</i> (Instruction Space) segment containing mostly <code>.text</code> and a <i>D-Space</i> (Data Space) segment
containing <code>.got</code>, <code>.data</code>, and <code>.bss</code> sections.
@ -518,6 +521,22 @@ cat ../syscall/syscall.csv ../lib/lib.csv | sort >tmp.csv
The option <code>-no-check-sections</code> is required to prevent the linker from failing because these segments overlap.
</p>
<p><b>NOTE:</b>
There are two linker scripts located at <code>binfmt/libnxflat/gnu-nxflat-gotoff.ld</code>.
</p>
<ol>
<li>
<b><code>binfmt/libnxflat/gnu-nxflat-gotoff.ld</code></b>.
Older versions of GCC (at least up to GCC 4.3.3), use GOT-relative addressing to access RO data.
In that case, read-only data (.rodata) must reside in D-Space and this linker script should be used.
</li>
<li>
<b><code>binfmt/libnxflat/gnu-nxflat-pcrel.ld</code></b>.
Newer versions of GCC (at least as of GCC 4.6.3), use PC-relative addressing to access RO data.
In that case, read-only data (.rodata) must reside in I-Space and this linker script should be used.
</li>
</ol>
<p><b>Target 4</b>.
Finally, this target will use the <code>hello.r2</code> relocatable object to create the final, NXFLAT module
<code>hello</code> by executing <a href="#ldnxflat"><code>ldnxflat</code></a>.