linker_feedback.txt 1.8 KB

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