12345678910111213141516171819202122232425262728293031323334353637383940 |
- The ARM documentation describes linker feedback here:
- http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0474c/CHDFJGBE.html
- Summed up by "Linker feedback is a collaboration between the compiler and
- linker that can increase the amount of unused code that can be removed
- from an ELF image". In a nut-shell: it is information generated by the
- link stage of a build that might usefully influence the compile stage in
- subsequent builds.
- Raptor supports ARM builds using linker feedback with RVCT via the
- ".linkerfeedback" variant and, from clean, it is a two stage process at its
- simplest e.g. :
- sbs -c armv5.linkerfeedback
- sbs -c armv5.linkerfeedback
- The first build sees a "normal" compile and link, with the exception that a
- .fdb linker feedback file is generated into the build tree by the linker.
- The second build is also a normal compile and link (re-compilation being
- triggered by a dependency of the object files on any .fdb found to exist)
- with the exceptions that:
- i) the pre-existing .fdb file is referenced in compiler calls
- ii) a "candidiate" .fdb file is generated by the linker and if (and only if)
- this differs from the pre-existing .fdb file then it is copied over the
- top to replace it
- Any further ".linkerfeedback" builds operate as above i.e. if the linker
- generates a candidate .fdb file different to that currently in use it is
- copied to where it will trigger re-compilation in subsequent builds.
- Note that, with builds from clean where no .fdb file exists, Raptor provides
- info output into the log and at the terminal to indicate that a further build
- is required to make use of the linker feedback file in later compilation:
- <info>Linker feedback file will be generated during the link of
- _ELF_FILE_ - re-build to use in compilation</info>
|