第八讲-基于ARM处理器开发过程(3课时).pptVIP

* * * * * * * * * * * * *** ANIMATED *** Purpose: In more detail, go over the rules which the linker observes when placing code and data. This provides useful background when we talk about scatterloading. The linker observes some basic rules to decide where code and data. The first level of the hierarchy is attribute. RO precedes RW precedes ZI. Within each attribute code precedes data. From there, the linker places input sections alphabetically by name. So, in this example, section A is placed before section B. Finally, within input sections, code and data from individual objects is placed in the order the object files are specified on the linker command line. So, in our example, any code in section A from file1.o is placed before any code from file2.o. In practice, the user is not advised to rely on these rules if precise placement of code and data is needed. Full control of placement of code and data is available through scatterloading (to be discussed later). =========== For the most part, the default section name for compiler output (and much of the library code) is “.text”. __main.o, gets a section labelled “!!!” (to ensure that it is placed first in a given region). At this point we haven’t mentioned execution regions, since we are discussing the “out-of-the-box” experience. All these rules are observed within each execution region. This point needs to be emphasized in the scatterloading section of this module. In reality, there is a distinction made between “output sections” and “input sections”. Output sections are really what is depicted on the left of the diagram. These are ordered by attribute (RO-code, RO-data etc…). This terminology was deliberately left out of the presentation because, although fundamental to the operation of the linker, it would introduce unnecessary confusion for the average user. If needed, a full discussion is in Section 3.1 of the ADS 1.2 Linker and Utilities Guide. Similar info in RVCT 2 docs too. * Purp