freescale中的RELOCATE_TO宏…

原文地址：freescale中的RELOCATE_TO宏定义作者：狼之行

在看网上的BOOLOADER程序资料时看到这个宏，不知何意故查看了下...

SEGMENTS: Define Memory Map (ELF)

Syntax

SEGMENTS {(READ_ONLY|READ_WRITE|NO_INIT|PAGED)

          <startAddr> (TO <endAddr> | SIZE <size>)

          [RELOCATE_TO Address]

          [ALIGN <alignmentRule>]

          [FILL <fillPattern>]

          {(DO_OPTIMIZE_CONSTS | DO_NOT_OPTIMIZE_CONSTS)

            { CODE | DATA }

          }

         }

END

Description

The optional SEGMENTS block cannot be specifiedmore than once in a prm file.

Use the SEGMENTS command to assign meaningful namesto address ranges. You can then use these names in subsequentPLACEMENT statements, thus increasing the readabilityof the parameter file.

Each address range you define is associated with:

• A qualifier.

• A start and end address or a start address and a size.

• An optional relocation rule

• An optional alignment rule

• An optional fill pattern.

• Optional constant optimization with Common Code commands.

Segment Qualifier

The following qualifiers are available for segments:

• READ_ONLY: used for address ranges which areinitialized at program load time.

• READ_WRITE: used for address ranges which areinitialized by the startup code at runtime. The linker initializesmemory area defined with this qualifier with 0 at applicationstartup.

• NO_INIT: used for address ranges where read/writeaccesses are allowed. The linker does not initialize memory areadefined with this qualifier at application startup. This may beuseful if your target has a battery-buffered RAM or to speed upapplication startup.

• PAGED: used for address range where read/writeaccesses are allowed. The linker does not initialize memory areadefined with this qualifier at application startup. Additionally,the linker does not control overlap between segments defined withthe PAGED qualifier. When using overlapped segments,it is your responsibility to select the correct page beforeaccessing the allocated data.

Qualifier Handling

Table E.5 Qualifier Handling

Qualifier

Initialized Variables

Non-Initialized Variables

Constants

Code

READ_ONLY

Not applicable (1)

Not applicable (1)

Content written to target address

Content written to target address

READ_WRITE

Content written into copy down area, along with startuplocation information. Area contained in zero out information (3,4)

Area contained in zero out information (4)

Content written into copy down area, along with startuplocation information. Area contained in zero out information (3,4)

Not applicable (1, 2)

NO_INIT

Not applicable (1)

Handled as allocated. Nothing generated.

Not applicable (1)

Not applicable (1)

PAGED

Not applicable (1)

Handled as allocated. Nothing generated.

Not applicable (1)

Not applicable (1)

• These cases are unintended, although the linker allows some ofthem. If allowed, the qualifier controls what is written into theapplication.

• To allocate code in a RAM area, declare this area asREAD_ONLY.

• Initialized objects and constants in READ_WRITEsections need RAM memory and space in the copy down area. The copydown contains the information about object initialization processin the startup code.

• The zero out information identifies areas to initialize with 0at startup. Because the zero out contains only an address and asize per area, it is usually much smaller than a copy down area,which also contains the (non-zero) content of the objects to beinitialized.

Example

SEGMENTS

  ROM   = READ_ONLY  0x1000 SIZE 0x2000;

  CLOCK = NO_INIT    0xFF00 TO   0xFFFF;

  RAM   = READ_WRITE 0x3000 TO   0x3EFF;

  Page0 = PAGED      0x4000 TO   0x4FFF;

  Page1 = PAGED      0x4000 TO   0x4FFF;

END

In this example:

• The ROM segment is a READ_ONLY memoryarea. It starts at address 0x1000 and its size is 0x2000 bytes(from address 0x1000 to 0x2FFF).

• The RAM segment is a READ_WRITEmemory area. It starts at address 0x3000 and ends at 0x3FFF (size =0x1000 bytes). This example initializes all variables allocated inthis segment with 0 at application startup.

• The CLOCK segment is a READ_WRITEmemory area. It starts at address 0xFF00 and ends at 0xFFFF (size =100 bytes). Variables allocated in this segment are not initializedat application startup.

• The Page0 and Page1 segments areREAD_WRITE memory areas. These are overlappingsegments. It is your responsibility to select the correct pagebefore accessing any data allocated in one of these segments. Thelinker does not initialize variables allocated in this segment atapplication startup.

Defining a Relocation Rule

Use the relocation rule if a segment is moved to a differentlocation at runtime. With the relocation rule, you instruct thelinker to use different runtime addresses for all objects in asegment.

This is useful when at runtime the code is copied and executedat a different address than the linked location. One example is aFlash programmer which must run out of RAM. Another example is aboot loader, which moves the actual application to a differentaddress before running it.

Specify a relocation rule as follows:

RELOCATE_TO Address

Use <Address> tospecify the runtime address of the object.

Example

SEGMENTS

    CODE_RELOC  = READ_ONLY 0x8000 TO 0x8FFF RELOCATE_TO 0x1000;

...

END

In this example, references to functions in CODE_RELOC useaddresses from 0x1000 to 0x1FFF area, but the code is programmedfrom 0x8000 to 0x8FFF.

With RELOCATE_TO, you can execute code at anaddress different from where it was allocated. The code need not beposition independent (PIC), however, non-PIC code may not run atits allocation address, as all references in the code refer to theRELOCATE_TO address.

NOTE

Usually the RELOCATE_TO address is in RAM. The linkerdoes not check for overlaps in the RELOCATE_TO address area. Set up the prmfile so that no overlapping is possible.

Defining an Alignment Rule

You can associate an alignment rule with each segment in theapplication. Use this feature when specific alignment rules areexpected on a certain memory range.

Specify an alignment rule as follows:

ALIGN [<defaultAlignment>] [{'['(<Number>|

    <Number> 'TO' <Number>|

    ('<' | '>' | '<=' | '>=')<Number>)']:'<alignment>}]

Use the defaultAlignment argument to specify thealignment factor for objects not matching any condition in thefollowing alignment list. If you do not specify an alignment list,the default alignment factor applies to all objects allocated inthe segment. The default alignment factor is optional.

Example

SEGMENTS

    RAM_1  = READ_WRITE 0x800 TO 0x8FF

             ALIGN 2 [1:1];

    RAM_2  = READ_WRITE 0x900 TO 0x9FF

             ALIGN [2 TO 3:2] [>= 4:4];

    RAM_3  = READ_WRITE 0xA00 TO 0xAFF

             ALIGN 1 [>=2:2];

END

In this example:

• RAM_1 segment: Aligns all objects of size equal to1 byte on 1-byte boundaries. Aligns all other objects on 2-byteboundaries.

• RAM_2 segment: Aligns all objects of size equal to2 or 3 bytes on 2-byte boundaries. Aligns all objects of sizegreater than or equal to 4 bytes on 4-byte boundaries. Objects ofsize equal to 1 byte follow the default processor alignmentrule.

• RAM_3 segment: Aligns all objects of size greaterthan or equal to 2 bytes on 2-byte boundaries. Aligns all otherobjects on 1-byte boundaries.

Alignment rules that apply during object allocation aredescribed in the alignment chapter.

Defining a Fill Pattern

You can associate a fill pattern with each segment in theapplication. This can be useful for automatically initializinguninitialized variables in the segments with a predefinedpattern.

Specify a fill pattern as follows:

FILL <HexByte> {<HexByte>}

NOTE

Any segment defined with the FILL command in theSEGMENTS portion of the prm file fills only if thesegment is also used in the PLACEMENT section of theprm file. If necessary, add a dummy entry to thePLACEMENT section.

Example

 SEGMENTS

     RAM_1  = READ_WRITE 0x800 TO 0x8FF

              FILL 0xAA 0x55;

 END

 PLACEMENT

     DUMMY  INTO RAM_1

 END

This example initializes uninitialized objects and filling byteswith the pattern 0xAA55.

If the size of an object to initialize is greater than the sizeof the specified pattern, the pattern repeats as many time asnecessary to fill the objects. In this example, an object with asize of 4 bytes initializes with 0xAA55AA55.

If the size of an object to initialize is less than the size ofthe specified pattern, the pattern truncates to match the size ofthe object. In this example, an object with a size of 1 byteinitializes with 0xAA.

When the value specified in an element of a fill pattern doesnot fit into a byte, it truncates to a byte value.

Example

 SEGMENTS

     RAM_1  = READ_WRITE 0x800 TO 0x8FF

              FILL 0xAA55;

 END

This example initializes uninitialized objects and filling byteswith the pattern 0x55. The specified fill pattern truncates to a1-byte value.

Fill patterns are useful for assigning an initial value to thepadding bytes inserted between two objects during objectallocation. This allows marking from the unused position with aspecific marker and detecting them inside of the application.

For example, you can initialize an unused position inside asection of code with the hexadecimal code for the NOPinstruction.

Optimizing Constants with Common Code

You can allocate constants having the same byte pattern to thesame addresses. The most common usage is to allocate some string inanother string.

Example

const char* hwstr="Hello World";

const char* wstr= "World";

The string Hello World contains the stringWorld exactly. When the constants are optimized,wstr points to hwstr+6.

In the Freescale format, the linker only optimizes strings. Inthe ELF format, all constant objects, including strings, constantsand code, can be optimized.

For all segments you can specify whether to optimize code ordata (only constants and strings). If nothing is specified,-Cocc controls the default (see -Cocc: Optimize Common Code (ELF)).

Examples

Listing E.9 C-Source File

void print1(void) {

  printf("Hello");

}

void print2(void) {

  printf("Hello");

}

Listing E.10 Prm File

SECTIONS

    ...

    MY_ROM = READ_ONLY 0x9000 TO 0xFEFF DO_OVERLAP_CONSTS CODE DATA;

END

If you optimize data only, the string Hello appearsonce in the ROM-image. Optimizing both code and data allocates theprint1 and print2 functions at the sameaddress. However, if you optimize code only (this is not the casehere), then print1 and print2 are notoptimized because they use different instances of the stringHello.

If you optimize code only, the linker issues the warning:

L1951: Function print1 is allocated inside of print2 withoffset 0. Debugging may be affected.

The linker issues this warning because the debugger cannotdistinguish between print1 and print2, sothe wrong function might display while debugging. This does not,however, affect the runtime behavior.

The linker detects certain branch distance optimizations done bythe compiler because of the special fixups used. If the linkerdetects this type of optimization, neither the caller and thecallee are moved into other functions. However, other functions canstill be moved into them.

NOTE

Switching off the compiler optimizations can produce smallerapplications, if the compiler optimizations prevent linkeroptimizations.

In C++, several language constructs result in identicalfunctions in different compilation units. Different instances ofthe same template may have identical code. Compiler-generatedfunctions, and inline functions not actually inlined, are definedin every compilation unit. Finally, constants defined in headerfiles are static in C++, so they are also contained once in everyobject file.