Recent manual updates for IAR XLINK

This document is a supplement to the XLINK Release Notes, and contains recent changes to the XLINK manual. Each section or sub-section is marked with the XLINK version of its most recent change. No attempt is made to represent a history of changes in this file. It documents only the current state of affairs.

If you are using XLINK in the Embedded Workbench integrated development environment, you may need a newer version of the Embedded Workbench for the relevant target in order to take full advantage of recently added features.

[4.59E]

Added output formats

[4.60G]

IEEE-695 details

[4.59Y]

XCOFF78K details

[6.1.3.56]

Checksums and fillers (-H -J -h)

[5.1.0.8]

Revised segment placement (-Z -P)

[6.0.0.46]

ELF details

[4.51D]

Address expressions

[6.0.0.46]

UBROF versions

[4.61I]

Address translation (-M)

[6.0.0.46]

COFF details

[4.59K]

Scatter loading (-Q)

[6.2.0.62]

Diagnostics control (-w)

[6.0.0.46]

Relocation areas (-V)

[4.55F]

Range errors

[4.56B]

Address space sharing (-U)

[6.2.0.62]

[4.59K]

[6.2.0.62]

[6.1.2.53]

[5.3.0.22]

[6.2.0.62]

Added output formats

4.59E - Simple-code

simple-code

4.59E - Raw-binary

XLINK can now generate raw-binary format output. Raw-binary is a binary image format. It contains no header, no starting point, no address information of any kind, nothing but pure binary data. The first byte of the file is the first byte in the program. The file contains all bytes between the first and the last byte in the program, including any and all gaps. Note that there is no way to discern the entry address of the program from the contents of the file, no such information is available in the file and it must thus be kept tracked of in some other way, perhaps in the file's name.

4.52A - MOTOROLA-S19, MOTOROLA-S28 and MOTOROLA-S37

motorola

motorola-s19:: Uses the S1 and S9 record types, which use 16-bit addresses.
motorola-s28:: Uses the S2 and S8 record types, which use 24-bit addresses.
motorola-s37:: Uses the S3 and S7 record types, which use 32-bit addresses.

motorola

4.51J - COFF

COFF section

4.51C - ELF

ELF section

4.51A - IEE659-M, IEEE659-IS, and IEEE659-IE

Example:

-Fieee695-ie -ygbr,1

4.49J - AOMF80251

The output format AOMF80251 is an Intel object format for 80251 processors. XLINK follows the "Object Module Format 251 Specification" revision 1.7.

4.51D - UBROF, UBROF5, UBROF6, UBROF7, and UBROF8

In conjunction with this several new output formats have been added to XLINK:

     -Fubrof5   Output UBROF 5 even if any input was UBROF 6
     -Fubrof6   Output UBROF 6 even if no input was UBROF 6
     -Fubrof7   Output UBROF 7 even if no input was UBROF 7
     -Fubrof8   Output UBROF 8 even if no input was UBROF 8
     -Fubrof    Output UBROF (a synonym for -Fdebug)

4.49A - SIMPLE

The SIMPLE output format is a very simple binary output format. Source code for a SIMPLE reader is provided to make it easy to handle particular output requirements at a customer site. See the SIMPLE subdirectory.

4.48J - IEEE695

The output format IEEE-695 is supported only for certain combinations of processors and debuggers/emulators. See the IEEE-695 section of this document for more information about this and other issues regarding the IEEE-695 format.

4.48F - MSP430_TXT

The output format msp30_txt is a simple output format used in Texas Instruments Starter Kits.

4.48B - XCOFF78K

The output format xcoff78k is a NEC proprietary format and is supported only for the NEC 78k series of processors. See the xcoff78k section of this document for more information about this format.

IEEE-695 details

4.51A - Format variant modifiers.
XLINK supports a number of format variant modifiers that govern particular subtleties in the IEEE-695 output format through the use of the -y command line option. Combinations of format variant modifiers can be used by specifying more than one flag character in a single -y command line option. For example, -ygl makes XLINK output global types both globally and in each module.
The available format variant modifiers for IEEE-695 are:
```
-yg  Output global types globally
```
```
-yl  Output global types in each module
```
```
-yb  Treat bit sections as byte sections
```
```
-ym  Adjust output for Mitsubishi PDB30 debugger
```
```
-ye  No block-local constants
```
```
-yv  Handle variable life times
```
```
-ys  Output stack adjust records
```
```
-ya  Output module locals in BB10 block
```
```
-yr  Last return refers to end of function
```
```
-yd  No #define constants
```

4.60G - Updated

Recommended settings for some combinations of cpus and debuggers are:

    6812     Noral debugger                     -ygvs
    68HC16   Microtek debugger                  -ylb?
    740      Mitsubishi PD38                    -ylbma
    7700     HP RTC debugger                    -ygbr
    7700     Mitsubishi PD77                    -ylbm
    H8300    HP RTC debugger                    -ygbr
    H8300H   HP RTC debugger                    -ygbr
    H8S      HP RTC debugger                    -ygbr
    M16C     HP RTC debugger                    -ygbr
    M16C     Mitsubishi PD30/PDB30/KDB30        -ylbm
    R32C     PD30, PD308, PD77, PD100           -ylmb
    T900     Toshiba RTE900 m25                 -ygbe
    T900     Toshiba RTE900 m15                 -ygbed

4.60G Supported targets - Introduced
The IEEE-695 format is currently supported for the 6811, 6812, 68HC16, 740, 7700, 78k, H8300, H8300H, H8S, M16C, MC80, M32C, R32C, T900 and Z80 target processors.

XCOFF78K details

4.59Y - New cpu variant NEC 78K0R - Introduced
Starting with the 4.59Y release XLINK supports output in the xcoff78k output format for the NEC 78K0R processor. The recommended format variant for the NEC ID78K0R-QB debugger is -ysp (truncate symbols and strip source file paths).
4.59J - Format variant modifiers - Updated
XLINK supports a number of format variant modifiers that govern particular subtleties in the xcoff78k output format through the use of the -y command line option. Combinations of format variant modifiers can be used by specifying more than one flag character in a single -y command line option. For example, -ysp makes XLINK truncate symbols to 31 characters and strip source file paths.
The available format variant modifiers for xcoff78k are:
```
-ys  Truncate symbols to 31 characters
```
```
-yp  Strip source file paths
```
```
-ye  Include module enums
```
```
-yl  Hobble line number info
```
```
-yn  Sort line numbers in ascending order
```

Checksums and fillers (-H -J -h)

6.1.3.56 - Checksum summary - Introduced
--output_checksum_summary[=verbose]
Outputs a summary, name and checksum value, of all checksums in the program in the summary of the link job. Complete checksum information is available in the map file. Example:
IAR Universal Linker V6.1.3.56 Copyright 1987-2014 IAR Systems AB. 245 bytes of CODE memory (+ 179 range fill ) 130 bytes of DATA memory Crc: __checksum 0xaa09 Errors: none Warnings: none
If the verbose version is requested (--output_checksum_summary=verbose), complete checksum information (the same that is available in the map file) will be output instead of summarized version.

5.5.0.33 - Endianess control - Introduced
-Jsize,algo[,flags...
The new 'x' flag to the -J option reverses the endianess of the computed checksum.
Examples:
-J2,crc16,x=4000-7FFF Checksum from 0x4000 to 0x7FFF using the crc16 algorithm and generate a 2-byte checksum in the reversed endianess.
-J4,crc32,m2Wx=0-FFFF Checksum from 0x0 to 0xFFFF using the crc32 algorithm. Checksum 16 bits with reversed bit order in each iteration and generate a 4-byte 2's complement checksum with reversed endianess.
Examples of reversed endianess:
If the 1-byte checksum was 0x73 the reversed checksum will be 0x73.
If the 2-byte checksum was 0xC2 the reversed checksum will be 0xC200.
If the 4-byte checksum was 0x3AC25 the reversed checksum will be 0x25AC0300.

5.3.0.22 - Checksum units larger then 8 bits - Introduced
-Jsize,algo[,flags... XLINK now supports the use of a checksum unit length larger than then 8 bits. This is primarily used to make the linker generated checksum match the one computed by special CRC hardware that checksums more than 8 bits in every iteration.
Three different sizes are currently supported, 8 bits (this is the default), 16 bits (W flag) and 32 bits (L flag).
Examples:
-J2,crc16,L=4000-7FFF
Checksum from 0x4000 to 0x7FFF using the crc16 algorithm. Checksum 32 bits in each iteration and generate a 2-byte checksum.
-J4,crc32,m2W=0-FFFF
Checksum from 0x0 to 0xFFFF using the crc32 algorithm. Checksum 16 bits with reversed bit order in each iteration and generate a 4-byte 2's complement checksum.

If the length of the specified range (or the size of the segment if using the {SEGMENT_NAME} notation) is not a multiple of the checksum unit length error 181 or error 182 is generated.

5.3.0.22 - Private fillstrings - Introduced
-h['fillstring']ranges[;ranges...]
XLINK now supports private fill strings, a fill string that is only used in one fill command. The fill string must have an even length and every specified character must be a hexadecimal digit (0-F). Specifying several fill commands for the same address generates error 179.
Examples:
-h'DEADBEEF'(CODE)80-2FF
This fills unused space in the range from 0x80 to 0x2FF with the bytes 0xDE 0xAD 0xBE 0xEF.

-h'1895'0-3F
This fills unused space in the range from 0x0 to 0x3F with the bytes 0x18 0x95.

4.61T - Literal checksum ranges - Introduced
Starting with XLINK 4.61T it is possible to specify the exact order of the checksummed bytes. In the normal case the bytes are specified and XLINK is free to pick any suitable order that includes the specified bytes and a byte is only checksummed once, regardless of how many times the address of the byte is specified.
-Jsize,algo[,flags[,sym[,seg[,align[,[m][#]initial]]]]]][=[=]CHECKSUM_RANGES]
Using == instead of = when specifying ranges will result in the specified ranges being checksummed in exactly that order. A byte will be checksummed as many times as it is specified.
Example:
This will checksum every byte from 0x200 to 0x9FF and each byte will be checksummed exactly once even though the bytes between 0x600 and 0x7FF where specified twice and 600-9FF was specified before 200-7FF.
This will checksum the range 0x200 to 0x7FF and then 0x600 to 0x9FF, the overlapping bytes (0x600 to 0x7FF) will be checksummed twice.

4.61L - Checksumming of segments by name - Introduced
Starting with XLINK 4.61L it is possible to specify the name of a segment in a checksum command. This will add the start and end address of the segment to the range that is checksummed.
-Jsize,algo[,flags[,sym[,seg[,align[,[m][#]initial]]]]][=CHECKSUM_RANGES]
CHECKSUM_RANGES is specified using RANGE[;RANGE...]
RANGE is one of:
- An explicit range of hexadecimal addresses, like 200-5FF.
- A symbolic range, like CHECKSUM_START-CHECKSUM_END.
- A segment name inside a {}-pair, like {CODE}.
An address is only used once, regardless of how many time it is specified in the ranges of checksum command. Example:
-J2,crc16=CRC_START-CRC_END,40-7F,{CODE}
If CRC_START has the value 40, CRC_END has the value 4F and the segment CODE resides on the addresses 50-113, the above checksum command is equivalent to writing: -J2,crc16=40-4F,40-7F,50-113. The ranges overlap so this is equivalent to -J2,crc16=40-113. The checksumming will start on address 40 and end on address 113, the byte on each address will be used exactly once even though some addresses were specified in more then one range.

4.61C - Bytewise and mirrored initial checksum values - Introduced

Starting with XLINK 4.61C, it is possible to specify bytewise initial values and mirrored initial values. The syntax for this does not add any new expressive power; every bytewise and/or mirrored initial value can be expressed equally well as a bitwise non-mirrored initial value. (By default, initial values are non-mirrored.) Specifying bytewise and mirrored initial values is simply a convenient way of specifying the same initial value both in XLINK and in the verification step, in cases where the verification step uses bytewise or mirrored initial values.

Note: Mirroring is the process of reversing all the bits in a binary number,see mirroring below.

Specifying initial values

-Jsize,algo[,flags[,sym[,seg[,align[,[m][#]initial]]]]][=ranges[;ranges...]]

Initial values are specified like this:


`initial`	The initial value in hexadecimal form. If nothing else is specified this is a bitwise initial value.
`#`	This specifies that `initial` is a bytewise initial value.
`m`	This specifies that the initial value `initial` will be mirrored before it is used.
Examples:
`0x4711`	This is a bitwise initial value.
`#0x1D0F`	This is the bytewise initial value.
`m0x2468`	This is a bitwise initial value that will be mirrored (0x2468 before mirroring).
`m#0x8C18`	This is a bytewise initial value that will be mirrored (0x8C18 before mirroring).

Bitwise initial values

If a bitwise initial value is specified on the checksum command line, that value is used as the initial value of sum in the classic bit-by-bit crc calculation below.

#define POLY 0x1021  /* for crc16 */

uint16_t
bit_by_bit_crc(uint16_t sum, uint8_t *p, unsigned int len)
{
  while (len--)
  {
    int i;
    uint8_t byte = *p++;

    for (i = 0; i < 8; ++i)
    {
      uint16_t osum = sum;
      sum <<= 1;
      if (byte & 0x80)
        sum |= 1 ;
      if (osum & 0x8000)
        sum ^= POLY;
      byte <<= 1;
    }
  }
  return sum;
}

Note: For an N-byte checksum you need to feed N x 8 zero bits through the bit-by-bit algorithm after the last bit has been entered. This allows the last N x 8 bits of the checksum to "trickle" out.

Command line example

-J2,crc16,,,,,0x4711
The above command line option specifies a 2-byte crc16 checksum where the initial value of sum in the bit-by-bit C-function above would be 0x4711.

Additional information

See technical note 91733 for more details about bit-by-bit crc:s. The bit-by-bit algorithm is called slow crc in IAR technical support documentation.

Bitwise initial values are sometimes called indirect initial values in texts about crc.

Bytewise initial values

If a bytewise initial value is specified on the command line, that value is used as the initial value of sum in the byte-by-byte crc calculation below.

Byte-by-byte crc algorithms are faster than bit-by-bit crc algorithms. The byte-by-byte algorithm below executes faster but uses more space than the bit-by-bit algorithm above. It uses a table of precomputed crc values. (See technical note 91733 for more information about crc tables.)

unsigned short
byte_by_byte_crc(uint16_t sum, uint8_t *p, unsigned int len)
{
  while (len--)
    sum = table[(sum >> 8) ^ *p++] ^ (sum << 8);
  return sum;
}

Note: The byte-by-byte algorithm does not need any final zero bits.

Command line example

-J2,crc16,,,,,#0x1D0F
The above command line option specifies a 2-byte crc16 checksum where the initial value of sum in the byte-by-byte C-function above would be 0x1D0F.

The byte-by-byte algorithm computes exactly the same checksum as the bit-by-bit algorithm (once the final zeroes have been fed through the bit-by-bit algorithm). They cannot use the same initial value due to differences in how the initial value is handled.

Additional information

See technical note 91733 for more details about byte-by-byte crc. The byte-by-byte algorithm is called fast crc in IAR technical support documentation.

Bytewise initial values are sometimes called direct initial values in texts about crc:s.

Mirrored initial values

If an initial value is specified on the checksum command line with the m prefix, that value is mirrored before it is used.

Mirroring is the process of reversing all the bits in a binary number. If the number has N bits, bit 0 and bit N-1 are swapped, as is bit 1 and bit N-2 and so on.

Examples:

mirror(0x8000) = 0x0001 mirror(0xF010) = 0x080F mirror(0x00000002) = 0x40000000 mirror(0x12345678) = 0x1E6A2C48

Command line example

-J2,crc16,,,,,m0x480A
This specifies a 2-byte crc checksum with the bitwise initial value 0x5012. (0x480A interpreted as a 16-bit binary number and mirrored)

In XLINK, the size of the checksum determines the number of bits in the initial value that will be mirrored . -J4,...,m0x2000 specifies the bitwise initial value 0x00040000, not 0x0004, because the initial value is treated as a 4-byte quantity when the checksum size is 4 bytes.

Additional information

Mirroring is sometimes called reflection in texts about crc.

4.60I - Checksum value symbol - Introduced

Starting with XLINK 4.60I the generated output file (currently only UBROF and ELF/DWARF) will contain one extra symbol for each checksum symbol, the checksum value symbol. The checksum value symbol will have the same name as the checksum symbol but with an extra "__value" concatenated at the end. Thus the checksum value symbol for the default checksum name (__checksum) will be __checksum__value. The value of the checksum value symbol will be the calculated checksum of the checksum command, not the address of the checksum bytes (that is the value of the checksum symbol).

Note that this symbol cannot be accessed from the program as it is added after the link phase. The checksum value symbol is generated to help a debugger make a quick check to see if the code in target ROM is the same as that in a debug file.

Note also that there are circumstances in which the code will be different even though the checksums are the same. One such circumstance is for position-independent code that is located at different addresses in different images, since the checksum only depends on the contents of bytes, and not their addresses.

Example: The crc16 checksum for a program is 0x4711 and resides on the address 0x7FFE. The output file will, by default, contain the symbol __checksum with the value 0x7FFE and the symbol __checksum__value with the value 0x4711.

4.61C - Initial value - Updated

An initial value can now be specified for each checksum command. This initial value is listed in the linker listfile. Previous versions of XLINK always used the initial value 0, which is now the default.

-Jsize,algo[,flags[,sym[,seg[,align[,[m][#]init]]]]][=ranges[;ranges...]]

   size          Size of checksum: 1, 2, or 4 bytes
   algo          Algorithm: sum, crc16, crc32, or crc=poly
   flags         Complement: 1 or 2, Mirroring: m
   sym           Checksum symbol
   seg           Put checksum in segment seg
   align         Use alignment align for checksum
   init          Initial checksum value (defaults to 0)
                 m specifies a mirrored initial value
                 # specifies a bytewise initial value		 
   ranges        Calculate checksum from bytes in ranges

XLINK can generate an arbitrary number of checksums, each of which can be for any specified ranges of memory.

Each command line option specifies one checksum, which will be calculated from any bytes that occur in the given ranges. No bytes from the checksum itself, or from any checksums specified after it are incl uded in the calculation. The bytes are processed in order of increasing addresses.

If no symbol is specified, the name "__checksum" is used. In this case the symbol is also included in the final program. If a symbol name is explicitly specified, that particular checksum is only included in the final program if it is referenced by any included parts of the program, or if the -g (require global entries) command line option is used for the symbol.

If no segment name is specified, the name "CHECKSUM" is used.

If no alignment is specified, an alignment of 1 is used.

If no ranges are specified, all bytes in the final program are included in the calculation.

The value of each checksum, and which bytes in what order were included in the calculation, is listed in the linker list file.

Examples:

-J2,crc16

Calculate a checksum using the CRC16 algorithm, create a segment part of size 2 in the CHECKSUM segment, defining the symbol __checksum. All available bytes in the program are included in the calculation.

-J2,crc16,2m,lowsum=(CODE)0-FF

Calculate a checksum that is the same value as above, except that it is the mirrored 2's complement of the result of the calculation. Create a segment part of size 2 in the CHECKSUM segment, defining the symbol lowsum. Only include bytes that fall into the range 0-FF in the CODE address space.

-J2,crc16,,highsum,CHECKSUM2,2=(CODE)F000-FFFF;(DATA)FF00-FFFF

Calculate a checksum of all bytes that fall in either of the ranges given. Place it into a segment part of size 2 with alignment 2 in the CHECKSUM2 segment, defining the symbol highsum.

4.51G - Filler bytes

The command line option "-H" can be used to generate filler bytes:

-Hhexstring

Fill all linker-introduced gaps between segment parts with the repeated hexstring. The linker can introduce gaps because of alignment restrictions, or to fill ranges given in segment placement options. The normal behavior, when no -H option is given, is that these gaps are not given a value in the output file.

The ranges that are filled are all the ranges into which segments with any content (code or constant data bytes) are placed. For a more explicit way to specify which ranges are filled, see the explanation of -h below.

Example:

-HBEEF

Fill all the gaps with the value 0xbeef. Even bytes will get the value 0xbe, and odd bytes will get the value 0xef.

4.51Q - Checksum generation
The command line option "-J" can be used to generate a checksum in the linker image:
Checksum all generated raw data bytes.
```
    size can be one of:
        1       One byte of checksum
        2       Two bytes of checksum
        4       Four bytes of checksum

    algorithm can be one of:
        sum     Simple arithmetic sum
        crc16   CRC16 (generating polynomial 0x11021)
        crc32   CRC32 (generating polynomial 0x4C11DB7)
        crc=n   CRC with a generating polynomial of n

    flags can be a combination of:
        1       One's complement
        2       Two's complement
        m       Mirror bytes
```
In all cases it is the least significant 1, 2 or 4 bytes of the result that will be output, in the natural byte order for the processor. The CRC checksum is calculated as if the following code was called for each bit in the input, most significant bit of each byte first, augmented with size (1, 2 or 4) bytes of zeros, starting with a crc of 0:
```
    unsigned long
    crc(int bit,
        unsigned long oldcrc)
    {
      unsigned long newcrc = (oldcrc << 1) ^ bit;
      if (oldcrc & 0x80000000)
        newcrc ^= POLY;
      return newcrc;
    }
```
POLY is the generating polynomial. The checksum is the result of the final call to this routine. If the mirror flag is given, the checksum is calculated with each byte bit-reversed, that is least-significant bit first, and then the result is also bit-reversed. If the 1 or 2 flag is given, the checksum is the one's or two's complement, respectively, of the result.
Note that the above routine is not a very time efficient way to calculate the checksum. See any text on crc calculation for faster ways. For checksums of size 2 or 1, the needed precision in the calculations will also be correspondingly lower. Also note that the checksum is calculated over the bytes in the input plus a number of zero bytes equal to the checksum size.
The linker will place the checksum byte(s) at the label __checksum in the segment CHECKSUM. This segment must be placed using the segment placement options like any other segment.
Example:
Calculate a 4 byte checksum using the generating polynomial 0x4C11DB7 and output the one's complement of the calculated value.

4.51M - Fill ranges
The command line option -h can be used to specify the ranges to fill. Normally, all ranges given in segment placement commands (-Z -P) into which any actual content (code or constant data) is placed are filled. For example:
```
    -Z(CODE)INTVEC=0-FF
    -Z(CODE)RCODE,CODE,CDATA0=0-7FFF,F800-FFFF
    -Z(DATA)IDATA0,UDATA0=8000-8FFF
```
If INTVEC contains anything the range 0-FF will be filled. If RCODE, CODE or CDATA0 contains anything the ranges 0-7FFF and F800-FFFF will be filled. IDATA0 and UDATA0 are normally only place holders for variables, which means that the range 8000-8FFF will not be filled.
The command line option -h can be used to explicitly specify which ranges to fill. Its syntax is:
That is, it can have an optional segment type (which can be used to specify address space for architectures with multiple address spaces) and one or more address ranges. For example:
or, equivalently, as segment type CODE is the default,
This will cause the range 0-FFFF to be filled, regardless of what ranges are specified in segment placement commands. Under many circumstances the use of -h will not be needed.
-h can be specified more than once, in order to specify fill ranges for more than one address space.
-h does not currently restrict the ranges used for checksum calculation. This may change in a future revision.

Revised segment placement

5.1.0.8 - Banked placement removed - Updated
Starting with XLINK 5.1.0.8 banked placement (-b) is no longer supported. Use equivalent -P commands to place segments instead.

4.61K - Alignment specification - Introduced
Starting with XLINK 4.61K It is now possible to increase a segment's alignment if the segment is placed using the -Z (sequential placement) placement command.
-Z[@][(segtype)]segment1[|align[|]][,segment2...][=ranges]
align can be any integer in the range 0-31
align is treated as a decimal number (XLINK uses hexadecimal by default, so this is an exception). align does not specify the desired alignment in bytes, but the number of bits that are forced to 0, starting from the least significant bit of the address. The alignment thus becomes 2 raised to the power of align, so 0 means no alignment (or 1-byte aligned), 1 means 2-byte aligned, 2 means 4-byte aligned, and so on. XLINK reports alignment in the segment map part of linker list files in this way.
Examples:
This option has no effect if the specified alignment is less than or equal the natural alignment of the segment.
If the alignment is followed by another vertical bar (like |2|) the size of the segment will become a multiple of the segment's alignment in addition to setting the alignment of the segment.
Examples:
4.61J - SPLIT - Updated
The SPLIT- modifier on the segment type in -Z placement commands was introduced as a workaround for a compiler problem. It is only intended for that specific purpose and using it for other purposes is strongly discouraged. See technical note 42795 for more information.
4.51T - Introduced
Segment placement is now both more convenient and more powerful while preserving compatibility with the old scheme. In the new scheme, -Z (sequential placement) and -P (packed placement) are the recommended segment placement command line options. -b (banked placement) is now deprecated, though it will likely stay around for a long time for compatibility reasons. -P now supports the functionality of -b in a more convenient and powerful fashion.
Previously, the memory ranges given to segment placement options basically had to be disjunct, since each placement option would place segment in isolation from all other placement options (with the exception of bit memory placement).
In the new scheme, all -Z and -P commands are considered in the order in which they were given, taking into account any memory occupied by previously placed segments, including segment duplication and anything placed at absolute addresses by the input files.
This makes it possible to place segments with less rigorous requirements in what is left over from placing segments with more strict requirements. For example, if we have two segments (Z1, Z2) that must be placed in the zero page (0-FF) and three (A1, A2, A3) that can be placed anywhere in available RAM (0-1FFF), we can now place them like this:
```
     -Z(DATA)Z1,Z2=0-FF
     -Z(DATA)A1,A2,A3=0-1FFF
```
This will place Z1 and Z2 from 0 up, giving an error if they do not fit into the range given, and then place A1, A2 and A3 from the first address not used by Z1 and Z2.
-P differs from -Z in that it does not necessarily place the segments (or segment parts) sequentially. See above for more information about -P. With -P it is possible to put segment parts into holes left by earlier placements.
Use -Z when you need to keep a segment in one consecutive chunk, when you need to preserve the order of segment parts in a segment, or, more unlikely, when you need to put segments in a specific order. There can be several reasons to do this, but most of them are fairly obscure. The most important is to keep variables and their initializers in the same order and in one block. Beginning with UBROF 7 the segments used for this have attributes that direct the linker to do the right thing, so -Z is no longer needed for these segments.
Use -P when you need to put things into several ranges, for instance when doing banking.
Bit segments are always placed first, regardless of where their placement commands are given.
Placement into far memory (FAR, FARCODE, FARCONST segment types) is the odd man out. In the old scheme, -Z placed segment parts consecutively, moving a segment part past a 64K boundary if needed. In the new scheme, -Z places the segments that fit entirely into the first page and range sequentially, and then places the rest using a special variant of sequential placement that can move an individual segment part into the next range if it did not fit. This means, as before, that far segments can be split into several memory ranges, but it is guaranteed that a far segment has a well-defined start and end.
There is a new modifier to the -Z segment placement command line option. -Z@ will give the old segment placement behavior of placing segments without taking into account any other use of the address ranges given. This is basically only useful if you actually want to get segment overlap.

ELF details

6.0.0.46 - Machine constants - Updated

These are the ELF machine constants used by XLINK.

Processor	Machine constant
6811	70
6812	53
6816	69
78K0R	199
AVR32	0x18AD
Coldfire	4
H8_300	46
H8S	48
M16C	0x1C20
MC80/M32C	0x1C80
R32C	162
RL78	197
S08	0x5308
SH	42
V850	070377

6.0.0.46 - Supported targets - Updated
The ELF format is currently supported for the 6811, 6812, 6816, 78K0R, AVR32, ColdFire, H8, M16C, MC80/M32C, R32C, RL78, SH and V850 target processors.
4.60K - New section - Introduced
- XLINK now generates the ".debug_pubnames" section, which contains information that enables accelerated access to debug information for some debuggers.
4.60K - Symbol table - Updated
- XLINK now outputs a size for function symbols. This field was previously always 0.
4.60K - Function static variables - Updated
- XLINK now outputs the correct (simple) name for block static variables, without a prefix indicating the scope.
4.59Q - New Sections - Introduced
- The new ".note.iar" section contains information about which type of offsets that are used (if -ys was specified) and if the Call Frame Information offsets are factored or not (if -yo was specified). This is of interest for debuggers that want to be able to read both variants.
- The new ".debug_aranges" section contains information about which addresses that a compilation unit places bytes at. This allows some debuggers to look things up quicker. If the debugger cannot handle the .debug_aranges section or if it for some other reason isn't wanted, it can be suppressed by specifying the -yw format variant modifier.

6.0.0.46 - Format variant modifiers - Updated
The available format variant modifiers for ELF/DWARF are:
```
-yb  Do not emit any .debug_pubnames section
```
```
-yc  Use address_class attributes for pointer types
```
```
-yf  Suppress DWARF Call Frame Information
```
```
-ym  Output types in each compilation unit, instead of once for all
```
```
-yn  Suppress DWARF debug output
```
```
-yo  Use non-factored CFA offsets in DWARF Call Frame Information
```
```
-yp  Multiple Elf program sections
```
```
-ys  Ref_addr (global refs) use .debug_info (not file) offsets
```
```
-yv  Use variant use_location semantics for member pointers
```
```
-yw  Do not emit any .debug_aranges section
```
```
-yx Strip source file paths, leaving only the file name and extension
```
As of version 4.51K of XLINK, ELF/DWARF format output includes module local symbols. The command line option -n can be used to suppress module local symbols in any output format.

6.0.0.46 - Recommended settings for some CPU:s and debuggers - Updated

       78K0R   Renesas                           -yspc
       H8      Renesas                           -yspcb
       M16C    Mitsubishi PD30                   -yspc
       M32C    Mitsubishi KD30                   -yspc
       R32C    Renesas                           -yspc
       RL78    Renesas                           -yspc
       V850    Lauterbach Trace32                -ys

4.51I - Format version - Updated
XLINK output conforms to ELF as described in "Executable and Linkable Format (ELF)", and DWARF version 2, as described in "DWARF Debugging Information Format" revision 2.0.0 (July 27, 1993), both part of the Tools Interface Standard Portable Formats Specification, Version 1.1.

Address expressions

4.51D - Address expressions
Addresses in command line options can now be given as expressions. Expressions must be enclosed in parentheses. Available operators are binary "*", "/", "%", "+", "-", "<<", ">>", "&", "^" and "|", with the same priorities as in C. Parentheses can be used for sub-expressions. Example:
```
     -Dfoo=1000
     -Dlen=1000
     -Z(CODE)CODE=foo-(foo+len-1)
```
The last line is equivalent to:

UBROF versions

4.51E - UBROF
UBROF, Universal Binary Relocatable Object Format, is an object format used by IAR's tools for both relocatable (into the linker) and absolute (out of the linker) object files.

6.0.0.46 - Brief history (updated)

UBROF has evolved through a number of revisions. The latest version of UBROF is UBROF 11.

     1986  UBROF 3    Assembler level linking. First release of this XLINK.
     1988  UBROF 4    Adds C information - types, source info, etc.
     1992  UBROF 5    Adds support for expanded set of IAR keywords.
     1997  UBROF 6    Source references. More compact representation
                      for files with many modules. Also adds detailed
                      version info.
     1998  UBROF 7    Further expanded type system for new generation
                      of compilers.
     1999  UBROF 8    Adds support for Embedded C++.
     2001  UBROF 9    Adds support for call frame information. Enhanced
                      statement information. Some improvements in variable
                      information.
                      UBROF 9.0 was a temporary release and has been
                      superseded by UBROF 9.1.
     2002  UBROF 10   Support for C++ templates
                      No limit on the number of segments in a module
                      No limit on the number of externals in a module
                      No limit on the number of types in a program
     2014  UBROF 11   NOALLOC content

6.0.0.46 - Supported versions (updated)
XLINK reads all UBROF versions from UBROF 3 onwards, and can output all UBROF versions from UBROF 5 onwards. There is also support for outputting something called "Old UBROF" which is an early version of UBROF 5, close to UBROF 4.
Normally XLINK outputs the same version of UBROF as used in its input files. More exactly, it uses the latest version found in the input files. If you have a debugger that does not support this version of UBROF, XLINK can be directed to use another version. This is done by using one of the command line options
```
     -Fubrof5
     -Fubrof6
     -Fubrof7
     -Fubrof8
     -Fubrof9
     -Fubrof10
     -Fubrof11
```
Old UBROF can be selected by using -Fdebug and the format variant option "-Y#".
For IAR's debugger, C-SPY, this is not a problem, which means that the command line option -r, which apart from specifying UBROF output also selects C-SPY specific library modules from the IAR standard library, always uses the same UBROF version as found in the inputs.
When XLINK outputs a version of UBROF that is earlier than the one used in its inputs there is almost always some form of debug information loss, though this can be minor if the input files do not make critical use of new features in the newer version of UBROF.
This debug information loss can consist of some of the following items. For each version this list contains information that cannot be represented, or not fully represented, in earlier versions of UBROF.
```
     UBROF 5    Up to 16 memory keywords resulting in different
                pointer types and different function calling
                conventions.
     UBROF 6    Source in header files. Assembler source debug.
     UBROF 7    Support for up to 255 memory keywords. Support for
                target type and object attributes. Enum constants
                connected to enum types. Arrays with more than 65535
                elements. Anonymous structs/unions. Slightly more
                expressive variable tracking info.
     UBROF 8    Embedded C++ object names. Added base types. Typedefs
                used in the actual types. Embedded C++ types:
                references and pointers to members. Class
                members. Target defined base types.
     UBROF 9    Call frame information. Function call step points.
                Inlined function instances.
     UBROF10	Templates.
     UBROF11    NOALLOC content.
     
```
In each case, XLINK attempts to convert the information to something that is representable in an earlier version of UBROF, but this conversion is, by necessity, incomplete and can cause inconsistencies. In many cases, though, notably when not much use is made of the new features, the conversion will result in something that is almost indistinguishable from the original as far as debugging is concerned.

Address translation

4.61I - Updated
Starting with XLINK 4.61I the address translation options generate a warning instead of an error when specified for an output format that does not support address translation. The address translation options have no effect for such output formats.
If a link job specifies address translation and generates several output files (-O) all generated files that are in a format for which address translation is supported will use translated addresses.

4.59P - Updated
XLINK now supports address translation for the ELF output format.

4.52B - Introduced
XLINK can now do logical to physical address translation on output for some output formats. Logical addresses are the addresses as seen by the program, and these are the addresses used in all other XLINK command line options. Normally these addresses are also used in the output object files, but by using a new command line option, "-M", a mapping from the logical addresses to physical addresses, as used in the output object file can be established.
The syntax of the -M command line option is:
This is very similar to a segment placment command line option (-Z and -P), except that both logical_ranges and physical_ranges are lists of address ranges.
Each occurrence of -M defines a linear mapping from a list of logical address ranges to a list of physical address ranges, in the order given, byte by byte. For example:
will define a mapping
```
     logical addresses 000-0FF map to physical addresses 1000-10FF
        "        "     200-2FF  "        "         "     1100-11FF
        "        "     300-3FF  "        "         "     1400-14FF
```
Several -M command line options can be given to establish a more complex mapping.
Address Translation can be useful in banked systems. Assume a code bank at address 0x8000 of size 0x4000, replicated 4 times, occupying a single physical ROM. If we want all the banks using physically contiguous addresses in the output file, we can use:
```
     -P(CODE)BANKED=[8000-BFFF]*4+10000         // Place banked code
     -M(CODE)[8000-BFFF]*4+10000=10000          // Single ROM at 0x10000
```
This means that the new segment placement commands (-P, -Z) can now replace all uses of the old banked segment placement command (-b). The last significant remaining feature of -b to support was the limited address translation provided by -b@ and -b#. Address translation is a more general and more powerful replacement.
Address translation only works for some output formats, primarily the simple formats with no debug information. This is the current list of supported output formats:
```
     aomf80196          aomf8051         aomf8096
     ashling            ashling-6301     ashling-64180
     ashling-6801       ashling-8080     ashling-8085
     ashling-z80        extended-tekhex  hp-code
     intel-extended     intel-standard   millenium
     motorola           mpds-code        mpds-symb
     pentica-a          pentica-b        pentica-c
     pentica-d          rca              symbolic
     ti7000             typed            zax
```

COFF details

6.0.0.46 - Removed
Starting with the 6.0.0.46 release, output in the COFF output format is no longer supported.

Scatter loading (-Q)

4.59K - Updated
XLINK can now do automatic setup for copy initialization of segments (scatter loading). The new command line option -Q uses the following syntax:
This will cause the linker to generate a new segment `initializer_segment' into which it will place all data content of the segment `segment'. Everything else, for instance symbols and debugging information, will still be associated with the segment `segment'. The intent is that startup code in the application will then at runtime copy the contents of `initializer_segment' (in ROM) to `segment' (in RAM).
This is very similar to what compilers do for initialized variables and is primarily intended to be used for code that needs to be in RAM memory.
The segment `initializer_segment' must be placed like any other segment using the segment placement commands.
Here's an example. Assume that the code in the segment RAMCODE should be executed in RAM. Scatter loading can be used to make the linker transfer the contents of segment RAMCODE (which will be in RAM) into the (new) segment ROMCODE (which will be in ROM), like this:
Then RAMCODE and ROMCODE need to be placed, using the usual segment placement commands. RAMCODE needs to be placed in the relevant part of RAM, and ROMCODE in ROM. Something like this:
```
     -Z(DATA)RAM segments,RAMCODE,Other RAM segments=0-1FFF
     -Z(CODE)ROM segments,ROMCODE,Other ROM segments=4000-7FFF
```
This will reserve room for the code in RAMCODE somewhere between address 0 and address 0x1FFF, the exact address depending on the size of other segments placed before it. Similarly, ROMCODE (which now contains all the original contents of RAMCODE) will be placed somewhere between 0x4000 and 0x7FFF, depending on the other stuff being placed into ROM.
At some time before executing the first code in RAMCODE, the contents of ROMCODE will need to be copied into it. This can be done as part of the startup code (in CSTARTUP) or in some other part of the code.

Example:

The example below is not intended as a guide on how to write code that is copied from ROM to RAM, but as an example on how it can be done without using the assembler. The only thing that needs to be added to this example is the -Q command and the placement commands for the segments RAMCODE and ROMCODE.

    /* include memcpy */
    #include <string.h>

    /* declare that there exists 2 segments, RAMCODE and ROMCODE */
    #pragma segment="RAMCODE"
    #pragma segment="ROMCODE"

    /* place the next function in RAMCODE */
    #pragma location="RAMCODE"

    /* this function is placed in RAMCODE, it does nothing useful, 
       it's just an example of an function copied from ROM to RAM */

    int adder(int a, int b)
    {
      return a + b;
    }     

    /* enable IAR extensions, this is necessary to get __sfb and __sfe,
       it is of course possible to write this function in assembler instead */
    #pragma language=extended

    void init_ram_code()
    {      
      void * ram_start   = __sfb("RAMCODE");  /* start of RAMCODE */
      void * ram_end     = __sfe("RAMCODE");  /* end of RAMCODE */
      void * rom_start   = __sfb("ROMCODE");  /* start of ROMCODE */

      /* compute the number of bytes to copy */
      unsigned long size = (unsigned long)(ram_end) - (unsigned long)(ram_start);

      /* copy the contents of ROMCODE to RAMCODE */
      memcpy( ram_start, rom_start, size );
    }

    /* restore the previous mode */
    #pragma language=default

    int main()
    {
      /* copy ROMCODE to RAMCODE, this needs to be done before anything 
         in RAMCODE is called or referred to */
      init_ram_code();

      /* call the function in RAMCODE */
      return adder( 4, 5 );
    }

Diagnostics control (-w)

6.2.0.62 - New diagnostics with different format
The new diagnostics can be controlled using the -w option.
Example:
The Ls014 diagnostic will no longer be generated.
The Ls015 diagnostic is now considered an error.
4.51N - Diagnostic IDs
As the severity of diagnostic messages can now be changed, the identity of a particular diagnostic now includes its original severity as well as its number. That is, diagnostic messages will typically be output as:
```
     Warning[w6]: Type conflict for external/entry ...
     Error[e1]: Undefined external ...
```
4.51N - Severity control for diagnostics
The -w option can now, in addition to its other uses, be used to change the severity of particular diagnostic messages using the following syntax:
<ID> is the id of a diagnostic message, which is the letter 'e' followed by an error number, the letter 'w' followed by a warning number, or just a warning number.
<severity> is one of 'i, 'w' or 'e'. If omitted it defaults to 'i'.
```
     i          Ignore this diagnostic. No diagnostic output.
     w          Emit a warning for this diagnostic.
     e          Emit an error for this diagnostic.
```
-w can be used several times in order to change the severity of more than one diagnostic.
Fatal errors are not affected by this option.
Some examples:
```
     -w26       Turn off warning 26
     -ww26            "
     -ww26=i          "
     -we106=w   Make error 106 be a warning
```
4.53A - Restrict output to a single address space
Output in the simple ROM output formats (intel-standard, intel-extended, motorola, motorola-s19, motorola-s28, motorola-s37, millenium, ti7000, rca, tektronix, extended-tekhex, hp-code and mpds-code) can now be restricted to include only bytes from a single address space by prefixing a format variant modifier with a segment type specifying the desired address space, in parentheses. This is particularly useful when used in combination with the multiple output files feature (-O).
Example:
This will result in two output files, both using the INTEL-EXTENDED output format. The first (named file1) will contain only bytes in the address space used for the CODE segment type, while the second (named file2) will contain only bytes in the address space used for the DATA segment type. If these address spaces are not the same, the content of the two files will be different.

Relocation areas (-V)

6.0.0.46 - Removed
Starting with the 6.0.0.46 release, relocation areas are no longer supported.

Range errors

4.55F - Updated

Starting with version 4.55D XLINK presents range errors (error 18) in a new way.

What is a range error?

Range error example

    Error[e18]: Range error, ARM branch target is out of range
      Where $ = vectorSubtraction + 0xC  [0x804C]
                in module "vectorRoutines" (vectorRoutines.r79),
                offset 0xC in segment part 5, segment NEARFUNC_A
      What: vectorNormalization - ($ + 8) [0x866B3FC]
      Allowed range: 0xFDFFFFFC - 0x2000000
      Operand: vectorNormalization [0x8673450]
               in module VectorNorm (vectorNormalization.r79),
               Offset 0x0 in segment part 0, segment NEARFUNC_V

Error[e18]: Range error

Where

0x804c

0xC

vectorSubtraction

The instruction is in the module vectorRoutines in the object file vectorRoutines.r79. Another way to express the address at which the instruction is located is as 0xC bytes into segment part 5 of segment NEARFUNC_A of the vectorRoutines module. This can be helpful in locating the instruction in the rare cases when no label can be supplied.

What:

0x8673450 - (0x804C + 8)

0x866B3FC

Allowed range:

-0x2000004 - 0x2000000

Operand:

Possible solutions

Possible solutions include:

Place the NEARFUNC_V segment closer to the segment NEARFUNC_A.
Use some other calling mechanism that can reach the required distance.

It is also possible that the referring function tried to refer to the wrong target and that this triggered the range error.

Different range errors have different solutions, usually the solution is a variant of the ones presented above.

Modify segment placement to avoid the problem.
Modify the code to avoid the problem.

Address space sharing (-U)

4.56B - Introduced (no longer experimental)

Each -U command line option declares that the memory given by the ranges on the left side of the '=' sign is the same memory as that given by the ranges on the right side. This has the effect that, during segment placement, anything occupying some part of either memory will be considered to reserve the corresponding part of the other memory as well.

The optional (segment type) that can be included on each side of the '=' sign can be used to specify the address space for architectures with multiple address spaces.

Example (assuming an architecture with separate code and address spaces and where the CODE segment type corresponds to the code address space and the DATA segment type to the data address space):

-U(CODE)4000-5FFF=(DATA)11000-12FFF
-P(CODE)MYCODE=4000-5FFF
-P(DATA)MYCONST=11000-12FFF

The first line declares that the memory at 4000-5FFF in the code address space are also mapped at 11000-12FFF in the data address space.

The second line places the MYCODE segment into the memory at 4000-5FFF in the code address space. The corresponding bytes in the data address space will also be reserved. If MYCODE occupies the addresses 4000-473F, the range 11000-1173F in the data address space will also be reserved.

The third line will place the MYCONST segment into what ever parts of the 11000-12FFF memory range are not reserved. In this case it will behave as if it were written: "-P(DATA)MYCONST=11740-12FFF".

-U is not transitive. That is, overlapping address space sharing command line options will not be distributed correctly to all involved address ranges. For example:

-U(CODE)1000-1FFF=(DATA)20000-20FFF
-U(DATA)20000-20FFF=(CONST)30000-30FFF

-U(CODE)1000-1FFF=(CONST)30000-30FFF

Stack Usage Analysis (--enable_stack_usage)

6.2.0.62 - Introduced

XLINK now supports Stack Usage Analysis. For some IAR Systems products and under the right circumstances, the linker can accurately calculate the maximum stack usage for each call graph root (each function that is not called from another function).

If you enable stack usage analysis (--enable_stack_usage or --stack_usage_control), a stack usage chapter will be added to the linker map file, listing for each call graph root the particular call chain which results in the maximum stack depth.

This is only accurate if there is accurate stack usage information for each function in the application. In general, the compiler will generate this information for each C function, but if there are indirect calls (calls using function pointers) in your application, you must supply a list of possible functions that can be called from each calling function. You can do this by using pragma directives in the source file, or by using a separate stack usage control file when linking.

If you use a stack usage control file, you can also supply stack usage information for functions in modules that do not have stack usage information. See the --stack_usage_control option in the XLINK manual. For more information about stack usage analysis (if your product supports it), see the IAR Compiler User Guide.

The output of stack usage analysis only is a complement to measurements. The actual stack usage in a program can be less than the listed amount. For instance, a call in the maximum call chain might be conditional and the condition for the call is never, by accident or by design, met. The function is then never called and the maximum call chain can never actually happen.

The actual stack usage might also be greater than the listed amount. This requires some kind of mistake somewhere; the information supplied by the compiler, the CFI in an assembler file, the override information in a suc-file a test expression in the check that-directive. It is usually a good idea to leave some safety margin in the check that-directive:

check that ((maxstack("Program entry") + maxstack("interrupt") + 10) < size("CSTACK"));

The analysis can also produce a more complete (not just the maximum call chain) call graph with stack depth in the linker log file.

MISRA C

4.59K - Introduced
Introduction
MISRA C is a subset of C, suited for use when developing safety-critical systems. The rules that make up MISRA C were published in "Guidelines for the Use of the C Language in Vehicle Based Software", and are meant to enforce measures for stricter safety in the ISO standard for the C programming language [ISO/IEC 9899:1990].
The implementation of the MISRA C rules does not affect code generation, and has no significant effect on the performance of IAR Embedded Workbench. The rules apply to the source code of the applications that you write and not to the code generated by the compiler. The compiler and linker only generate error messages, they do not actually prevent you from breaking the rules you are checking for.

MISRA C in XLINK
Beginning with XLINK 4.59B it is possible to check some of the MISRA C rules in XLINK. The rules in question are:
- 11, Identifiers (internal and external) shall not rely on significance of more than 31 characters. Furthermore, the compiler/linker shall be checked to ensure that 31 character significance and case sensitivity are supported for external identifiers.
- 23, All declarations at file scope should be static where possible.
- 25, An identifier with external linkage shall have exactly one external definition.
- 26, If objects or functions are declared more than once, they shall have compatible declarations.
Please consult IAR Embedded Workbench MISRA C document (supplied with IAR compilers that support MISRA C) for more information about the implementation of MISRA C in IAR's tools.

Options
There are two options in XLINK to control the MISRA C rules, these are:
```
   --misrac_verbose
   --misrac[=arg,arg,...]
     
```
--misrac_verbose turns on verbose output, this includes which rules that are checked
--misrac turns on individual rules. Note that only 4 of the rules are checked in XLINK.
Examples:
```
   --misrac=4,8,12            Turn on MISRA C rules 4, 8 and 12
   --misrac=27,12-23,9        Turn on MISRA C rules 9, 27 and all 
                              rules between 12 and 23
   --misrac=all               Turn on all MISRA C rules
   --misrac=required          Turn on the required MISRA C rules,
                              in XLINK this is rule 11, 25 and 26
```
When a rule is violated, XLINK generates an error. This can be changed by using the usual diagnostics control mechanism.

New diagnostics

6.2.0.62 - Introduced
These are introduced with the stack usage analysis functionality in 6.2.0.62.
```
   Ls000 could not open file "file"   
```
The file could not be opened. Make sure that the file exists in the specified location, that the tool has the correct include paths set up, and that the directory is not read- or write-protected.
```
   Ls001 expected tokens
```
At least one of the listed tokens was expected at the specified location. Use one of the listed tokens.
```
   Ls002 there is already 'possible calls' information for function
```
The listed function already has a possible calls declaration. Remove all possible calls declarations except one.
```
   Ls003 value out of range or illegal: value,
```
The listed stack usage value is not legal. Use a legal value.
```
   Ls004 there is already 'function' information for function
```
The function in question already has a function directive. Remove one of the declarations.
```
   Ls005 the name name matches more than one symbol
```
The listed name matches more than one symbol. Use a more specific pattern. Example: foo* matches both foo12 and foo34. Using the more specific foo1* matches only one of them.
```
   Ls006 the function function is already a call graph root in a different category
    "call graph root"
```
A function cannot be a call graph root in more than one category. Remove all call graph root declarations except one.
```
   Ls007 no function matching "function" found
```
No function matching the specified name was found. Make sure that your application actually contains a function with that name. If you tried to match a local function you will have to specify the module as well (see the stack usage analysis documentation in the IAR Compile User Guide).
```
   Ls008 a max recursion depth has already been set for this function (function)
```
The specified function already has a maximum recursion depth. Remove all specifications except one.
```
   Ls009 the function function matches both this directive and the one recursion depth specification, but the max depths are different
```
If a function matches more than one recursion depth specification, the maximum depth must be the same in all of them. Use a more specific pattern or change the recursion depth in at least one of the involved specifications.
```
   Ls011 zero depth not allowed
```
The maximum recursion depth of recursion nest cannot be 0.
```
   Ls012 max recursion depth conflict. "function" has a max depth 
         of value, but "function", which is in the same 
         recursion nest, has a max depth of value
```
If two or more functions reside in the same recursion nest they must use the same maximum recursion depth. Update the recursion depth specifications so that the depth specifications match.
```
   Ls013 [stack usage analysis] at least one function does not have
         stack usage information. Example: function. A
         complete list of such functions is in the map file.
```
The listed function (the complete list can be found in the map file) lacks stack usage information. Only annotated assembler files and C(++)-files compiled with a sufficiently modern compiler supply stack usage information.
When a function lacks information it can be supplied through the function directive in the stack usage control file.
```
   Ls014 [stack usage analysis] at least one function appears to be
         uncalled. Example: function A complete list of
         uncalled functions is in the map file.
```
The listed function (the complete list can be found in the map file) is included in the application but it does not appear to be called. Typically a function that is referenced by the application should be called by someone; otherwise it would not have been included.
This might be intentional (as with ROOT segment parts, interrupt functions or indirectly called functions), but if it is not it might be a missing reference (possibly from assembler code from a manual entry/override in the stack usage control file).
Various options in the stack usage control file can be used to silence this warning. The function can be included in the calls part of the function directive and the possible calls directive. It is also possible to use the no calls from directive.
```
   Ls015 [stack usage analysis] the program contains at least one
         indirect call.  Example: from function. A complete
         list of such functions is in the map file.
```
The listed function (the complete list of functions can be found in the map file) performs unknown indirect calls. The destination of indirect calls can be specified by using pragma directives (see the pragma directives documentation in the IAR Compiler User Guide) or in the stack usage control file (see the stack usage analysis documentation in the IAR Compiler User Guide).
```
   Ls016 [stack usage analysis] the program contains at least one
         instance of recursion for which stack usage analysis has not
         been able to calculate a maximum stack depth. One function
         involved is function A complete list of all recursion
         nests is in the map file.
```
The listed function (the complete list of functions can be found in the map file) performs recursive calls. The stack depth analysis cannot determine the maximum number of cycles in a recursive nest, but you can specify a maximum number in the stack usage control file (see the stack usage analysis documentation in the IAR Compiler User Guide).
```
   Ls017 [stack usage analysis] the function function is a call
         graph root, but there are calls to it
```
A call graph root cannot be called; if it is called it is not a root. Remove the call graph root specification or remove the call.
```
   Ls018 unable to get size of block
```
The size of the specified block (this will typically be the size of a stack segment) could not be computed. Check that the name of the block is correct and that a segment with that name actually exists in your application.
```
   Ls019 no stack usage could be calculated for at least one function
         in category "category"
```
The stack usage could not be calculated. The most likely explanations are missing stack usage information, unknown indirect calls or an unknown maximum recursions depth. These can all be taken care of by using pragmas or through the stack usage control file.
```
   Ls020 no call graph root function in category "category"
```
The specified category does not have a call graph root. Specify a call graph root in the stack usage control file (see the stack usage analysis documentation in the IAR Compiler User Guide).
```
   Ls021 check failed check failed text
```
The specified check that directive failed. This typically means that whatever the checks are supposed to detect just happened (like the computed stack size of your application exceeding the size of the allocated stack including the safety margin). Modify the test expression to allow the tested occurrence, or modify the application to pass the test.
```
   Ls023 evaluation error: expression
```
There was an error evaluating the expression. Check the expression carefully and make sure that, for example, sizes are not negative, there are no divisions by zero, etc.

New errors

6.1.2.53 - Introduced
```
   191 More than 2 gigabytes of fill could be needed for the specified range: range
```
The range (or at least one of the ranges) is larger than 2 gigabytes and generating that much fill will result in a very large output file. In the unlikely case that you actually want to generate that much fill you can disable this error with the usual Diagnostic control mechanism.
If a -h command caused this error you need to reduce the size of the range.
If range fill (-H without any -h commands) was used you can either use -h commands (as using -h disables range fill) or you can reduce the size of the relevant ranges in the segment placement commands. With range fill every ROM-address that is mentioned in a segment placement command will get a filler byte if no content is placed on that address.
6.1.0.51 - Introduced
```
   190 The range specification of the fill command "fill command" does not specify
       any addresses to fill.
```
The fill command needs an explicit range to fill. -h(CODE) does not instruct the linker to fill all CODE segments. Specify the range that you want to fill, see Checksums and fillers for details of the -h command.
6.0.3.49 - Introduced
```
   189 Unable to place the empty segment segment (align alignment). 
       At the moment of placement there were no available addresses where the 
       segment could be placed. Try changing the order the segments are placed in.
       description of the placement command
```
The segment (which is empty) cannot be placed. An empty segment does not occupy any space but the address that is assigned to it must still comply with the requested address range and alignment requirements must still be satisfied. In this case all of the allowed ranges from the placement command were occupied by other content and the empty segment could not be placed.
Empty segments can often be placed before segments with content as they do not consume any space (this is not strictly true, an empty segment with an alignment requirement can consume space). If you place segments in the order A,B,C where C is empty and could not be placed, you can try the order A,C,B or C,A,B instead. As long as it is not important that C is the last segment in the sequence the reordering should work.
If it is important that C is placed last there are few options left. You can try to extend the allowed placement range, you can try to reduce the space that the earlier segments use, and you can try to reduce the alignment requirement of the empty segment (assuming it has one).
6.0.0.46 - Introduced
```
   188 The processor processor is no longer supported.
```
The chosen processor is no longer supported. Use an older version of XLINK.
```
   187 The format output format is no longer supported.
```
The chosen output format is no longer supported. Use a different output format or use an older version of XLINK.
```
   186 The option option is no longer supported.
```
The chosen option is no longer supported. Use a different option or use an older version of XLINK.

5.8.0.42 - Introduced
```
   185 The workseg segment 'segment' is not included in the image.
```
The program does not contain a workseg segment with the requested name. If this error is overridden the start address of the workseg segment will be 0. This will most likely result in incorrect debug information for variables residing in the workseg.
```
   184 'Topic' is not a valid log request.
```
The requested topic is not supported. See Logging for information about supported topics.

5.5.0.33 - Introduced
```
   183 Static overlay map generation (-xo) is not supported for the
       processor processor.
```
This particular processor does not use the static overlay system. The -xo option is only accurate for static overlay systems so the information generated is potentially inaccurate. This error can be overridden using the normal Diagnostic control mechanism (-we183=...) but any information, gathered from use of the -xo option with this error disabled is potentially inaccurate. Stack usage information in particular is inaccurate as -xo handles information for static overlay systems, not for systems that use a stack, and there are fundamental differences between the two. Consult the XLINK manual about the -xo option.
5.3.0.22 - Introduced
```
   182 The checksummed segments segments have a size (size) 
       that is not a multiple of the specified checksum unit length
       (unit length). Use the aligned size option of the -Z
       segment placement option to extend the size to the desired
       multiple. For example: -Z(CODE)segments|2|
```
The checksum command uses a flag (L or W) that specifies a unit length larger than 8 bits (1 byte). The specified segment(s) do not have a size that is a multiple of that unit length so the checksum cannot be computed. The placement modifier |align| on segments placed with Z can be used to align the start and size of such segments (see the Z option for details of this, note in particular how alignment is specified).
```
   181 The checksum range address range has a size that is not a
       multiple of the specified unit length (unit length).
```
The checksum command uses a flag (L or W) that specifies a unit length larger than 8 bits (1 byte). The specified address range does not have a size that is a multiple of that unit length so the checksum cannot be computed. Update the range specification to match the unit length or skip the L or W flag.
```
   180 Bad filler string in fill option. A filler string must
       contain an even number of hex digits, and cannot be empty.
```
Every character in a filler string must be a hexadecimal digit (0-F). Every such character specifies 4 bits. Filler bytes in XLINK are byte oriented so 2 such characters are needed for every filler byte.
```
   179 The -h option fill option has an address range that overlaps
       previous segment fill options.
```
Only one filler string can be specified for a particular address. Change the fill ranges so every address has at most one specified fill range.
5.2.0.10 - Introduced
```
   177 No definition for 'function' provides all needed
       features: [list of features] Use the -e option if you
       want to select the function manually.
```
No supplied object file contains a version of the function that provides all of the required features. You can solve this by supplying an object file that provides a version of the function that provides all the features, or you can make sure that the program requires less features, or you can manually specify the function you want with the -e option.

5.1.0.8 - Introduced

   176 Relay Function Optimization is no longer supported from XLINK 5.1.0.
       You have to use an older version of XLINK to link this program.
       The module 'module' (file) contains at least one 
       MULTWEAK symbol.

Relay Function Optimization is not supported for this linker. You need to use an older version of XLINK or make sure that no needed module uses MULTWEAK symbols.

   175 Banked segment placement (-b, used in the placement command 
       placement command) is no longer supported. Use packed 
       segment placement (-P) instead.

4.61S - Introduced
```
   172 Output for the 'processor' processor in this byte order
       will use bi-endian code segments. This requires the code
       segments to be aligned (both start and size)
       to alignment bytes. The following segments do not have
       the required alignment:
       list of segments
```
Bi-endian code that is not properly aligned will not work. Align the listed segments using command line alignment specification (-Z(SEGTYPE)SEGNAME|ALIGNMENT|=..., consult the XLINK manual for how alignment is specified in segment placement commands) or make sure that the code is aligned in the compiler/assembler.
4.61L - Introduced
```
   171 The segment "segment" that is used in a checksum command
       is a packed segment.
```
Segment names used in a checksum command must be sequentially placed (placed using -Z). Place the segment using -Z or use explicit addresses (like 0x200-0x37F) in the checksum command.
```
   170 The segment "segment" that is used in a checksum command
       has not been defined.
```
The specified segment does not exist. Define it (using -Z) or use a different segment in the checksum command.
4.61K - Introduced
```
  169 Processor specific code fill (-hc) requires all ranges to be
      closed. The placement command "segment placement command"
      contains an open range.
```
All ranges must be closed in this case. Use either START-END or START:+SIZE to specify a closed range.
```
  168 Alignment error, segment part segment part number
      ("symbol") in the module 'module' (file)
      that generated the bi-endian content on address address
      does not have the required alignment.
```
Bi-endian code must be generated in such a way that every word of ROM is either entirely code or entirely non-code. For the word specified above this requirement is not met (parts of the word is code and parts of the word is non-code). If the object file was generated by the compiler this is probably a compiler bug. If the object file was generated by the assembler the code probably needs to be aligned and/or padded.
```
  167 Generation of bi-endian output files is not supported for the
      'output format' output format.
```
This output format does not currently support generation of bi-endian files. You must use another another format, or use the processor in a non bi-endian mode.
```
  166 In the chosen byte order for the processor processor, you
      must specify the code fill option (-hc) or the range fill option
      (-H without any -h option).
```
For this particular processor and this particular byte order, the code fill option must be specified (because of the special requirements of bi-endian code).
```
  165 A segment definition in segment placement command uses an
      alignment argument that is larger than the currently supported maximum
      (31).
```
XLINK currently only supports alignments up to and including (1 << 31) (byte-alignment). Remember that the alignment argument is the number of bits in the address that are forced to zero, not the byte-alignment. 2 results in a 4-byte aligned address, 3 in an 8-byte aligned address and so on.
```
  162 Alignment specification (|align[|]) is not allowed for segment names
      here: use of segment name
```
Alignment specification on segments are only allowed in a sequential segment placement command (-Z).

4.61J - Introduced
```
  164 The option command line option contains neither a number
      nor a command line symbol.
```
The indicated command line option contains characters that are neither part of a number (0-9 and A-F) nor valid in a symbol name, in a place where a number or a symbol was expected.
```
  163 The command line symbol "symbol" in command line option 
      is not defined.
```
The indicated command line option contains a symbol with an undefined value. Define the symbol (-Dsymbol=value) or use a symbol that is defined.
4.61C - Introduced
```
  161 The checksum command defined in checksum command
      specifies an initial value that does not fit in the size of the
      checksum.
```
The initial value specified is too large for the size of the checksum. Use a smaller initial value or increase the size of the checksum.
```
  160 No valid license found for this product. Information from 
      the license management system.
```
No valid license was found for at least one module that needed a license. You either don't have the required license or XLINK was unable to contact the license server.
4.61A - Introduced
```
  159 The file name "name" is not valid.
```
The specified name is not a valid file name on this system.

  158 The directory name "directory name" is not valid.

4.61A - Updated
```
   77 The absolute segment on the address address range in the module
      module (file) overlaps the absolute segment on the address 
      address range in the module module (file)
```
Two absolute segments overlap. You need to move at least one of them. You move absolute segments by modifying the source code.
```
   24 The absolute segment on the address address rangein the module
      module (file) overlaps the segment segment name 
      (from module module, address [address range])
```
An absolute segment overlaps a relocatable segment. You need to move either the absolute segment or the relocatable segment. You move absolute segments by modifying the source code. You move relocatable segments by modifying the segment placement command.

4.59M - Introduced

  156 Negative addresses are not allowed. The range declaration used 
      in range description is illegal as range start 
      is negative. Check the range specification for superflous parentheses, 
      (START-END) is an expression, not a range, START-END is a range.

The range declaration has a negative start value, this is not allowed. Check the range specification for superflous parentheses and check that the value of START and END are valid and that START <= END.

4.59L - Introduced
```
  154 The increment argument to -K for the segment segment resulted in 
      an invalid (negative or above 0xFFFFFFFF) address.
```
The duplication command for segment results in at least one duplicated segment that has an address below 0 or above 0xFFFFFFFF. You need to modify the -K command (the increment or the number of duplications) or move the segment to another address, to prevent this from happening.

4.59K - Introduced

  153 The input file 'file' has several forced properties which are 
      mutually exclusive

The input file has both the conditional and forced load properties, locate the -A and -C options and remove the file from one of them.

  152 The input file 'file' could not be found

The input file could not be found, check the include path.

  151 Internal consistency check failure, "error description"

An internal consistency check failed, this is to be considered an internal error but it is possible to force XLINK to generate output using -B.

  150 The stack depth for the call tree with root root is too large, 
      number bytes

The call tree uses more than the allowed number of stack bytes. Either increase the maximum allowed call depth, or decrease the depth of the call tree.

The following 4 errors, 146-149, are MISRA C errors.

  149 The symbol "symbol" in module module (file) is 
      public but is only needed by code in the same module - all declarations 
      at file scope should be static where possible (MISRA C rule 23)

  148 The names "name" and "name" differ only in characters 
      beyond position 31 - identifiers (internal and external) shall not 
      rely on significance of more than 31 characters (MISRA C rule 11)

  147 External "external" is declared in "file" and in
      "file" - external objects should not be declared in
      more than one file " "(MISRA C rule 27)

  146 Type conflict for external/entry "entry", in module module 
      against external/entry entry in module module - if objects or 
      functions are declared more than once, they shall have compatible 
      declarations (MISRA C rule 26)

4.59G - Updated

   20 Corrupt file.  External index out of range in module module(file)

The object file is corrupt. Contact IAR Systems.

4.58E - Introduced

  145 The banked segment segment contains segment parts that
      have properties that are unsafe when placed with -b (banked
      segment placement). Use -P (packed segment placement) instead.

      The segment contains at least one segment part that has a
      property that XLINK might be unable to honor when the segment is
      placed with -b. XLINK will be able to honor this property when
      -P is used so use that instead.

4.58A - Introduced

  144 The conditional reference at offset offset in segment 
      segment could not use its definition of last resort, 
      the entry in segment segment.

      In order for XLINK to be able to optimize the use of relay
      functions, each module must supply relay functions that can be
      used by every call site in that module. This error occurs when
      that precondition is not met. The distance between the reference
      and the definition may be too large, or the definition might be
      unsuitable because it is in the wrong processor mode, or for
      some other reason.

      If this occurs for a module produced by a compiler (as opposed
      to in assembler code), this is an indication of a problem in
      either the compiler or the linker. To test if the problem is in
      the linker, try linking with Relay Function Optimization
      disabled (-q).

4.56H - Introduced

  143 There is more than one PUBWEAK definition in the segment part 
      "segment part description".

      PUBWEAK definitions must be perfectly interchangeable. Segment
      parts with multiple PUBWEAK definitions cannot not always be
      interchanged with other definitions of the same symbols.

4.56E - Introduced

  142 Entries included in PUBWEAK/PUBLIC resolution must be in a named
      segment (RSEG or ASEGN). Discovered when resolving the PUBWEAK
      entry in module `module` against the PUBLIC 
      entry in module `module`.

      All symbols involved the PUBWEAK/PUBLIC resolution must be placed
      in either RSEG or ASEGN segments. Locate the assembler code that
      defines the involved symbol in an absolute segment (ASEG) and replace 
      it with a ASEGN segment definition. Consult your assembler manual for 
      the details on ASEG and ASEGN.

4.56E - Updated

  105 Recursion not allowed for this system. One recursive function is 
      function.

      The runtime model used does not support recursion. Each function
      determined by the linker to be recursive is marked as such in
      the module map part of the linker list file.

4.56B - Introduced

  141 The SPLIT- keyword in the packed segment placement command 
      placement command is illegal, SPLIT- is only allowed in 
      sequential placement commands (-Z).

      Only sequential placement commands can use SPLIT. Either use
      -Z or remove the SPLIT- keyword.

4.55B - Introduced

  140 The range declaration used in range declaration is 
      illegal since start > end.

      A range must have a positive size so the end must not
      be lesser than the start.
  
  139 Module module ( file ) uses relocations ( 
      relocation ) in ways that are not supported by the 
      format output format.

      The object file contains a relocation that cannot be 
      represented in this output format. This can be the result
      of assembly code using an instruction format not supported
      by the relocation directives in this output format.

  
  138 Module module ( file ) contains operations that cannot 
      be used with relocation areas:  error text 

      Somewhere in the module an address (relocation area + 
      offset) is used as if it were an absolute address. 
      That is not always an error since relocation areas 
      usually are aligned meaning that parts of address 
      might be ok to use.

      Is the module compiled/assembled with a modern 
      compiler/assembler that has support for relocatable output 
      (consult your manual if you are not sure)? Old 
      compilers/assemblers perform checks in ways that might 
      trigger this error (relocatable output will not work with 
      old compilers).

      Is the alignment of your relocation area large enough?
      Relocation areas are created using the -V option, see
      Relocation areas (-V) for details.

      Does the module contain handwritten assembly code? If 
      so, it is fairly probable that it uses some strange 
      expression that causes this error. 

      If the module was compiled with a modern compiler,
      your relocation areas has a sufficient alignment
      and you get this message, contact IAR Support.

  137 Duplicate relocation area: relocArea1 relocarea2

      A relocation area was defined twice. Each relocation area 
      needs a unique identifier.

  136 The output format 'format' does not support the use of relocation
      areas (-V option). Did you forget a format modifier flag?

      This output format does not support relocatable output.
      Either some format modifier flag (-y option) was not specified
      or the output format has no support for relocatable output.

  135 A module in the file file has an empty module name,
      which is not supported in the format output format.

      This output format is unable to handle empty module names,
      avoid this error by giving the module a name when you compile
      the source file.

  134 The left and right address ranges do not cover the same number 
      of bytes: range1 range2

      The left and right address ranges of this command line option need 
      to cover exactly the same number of bytes.

4.53A - Introduced

  
  133 The output format format cannot handle multiple address
      spaces. Use format variants (-y -O) to specify which address
      space is wanted

      The output format used has no way to specify an address
      space. The format variant modifier used can be prefixed with a
      segment type to restrict output only to the corresponding
      address space.

      For example, "-Fmotorola -y(CODE)" will restrict output
      to bytes from the address space used for the CODE segment type.

      See the section on multiple output files for more information.

  132 Module module ( file ) uses UBROF version 9.0. This version
      of UBROF was temporary and is no longer supported by XLINK

      Support for UBROF 9.0.0 has been dropped from XLINK starting
      with XLINK 4.53A.

4.52A - Introduced

  131 Far segment type illegal in packed placement command:
      "command". Use explicit address intervals instead. For
      example:
          [20000-4FFFF]/10000

      Using a far segment type (FARCODE, FARDATA,
      FARCONST) is illegal in packed placement (-P).

  130 Segment placement needs an address range: "command"

      The first segment placement command (-Z -P) must have
      an address range.

4.51K

  128 Segments cannot be mentioned more than once in a copy init
      command: "-Qargs"

      Each segment can only be either the source or the target of a
      copy init command.

  127 Segment placement command "command" provides no address range,
      but the last address range(s) given are not of the proper kind
      (bit addresses versus byte addresses).

      This error will occur if something like this is entered:

             -Z(DATA)SEG=1000-1FFF
             -Z(BIT)BITVARS=

      Note that the first uses byte addresses and the second needs bit
      addresses. To avoid this, provide address ranges for both.

4.51J

  126 Runtime Model Attribute "__cpu" not found. Please enter at
      least one line in your assembly code that contains the following
      statement: RTMODEL "__cpu","16C61". Replace 16C61 with your
      chosen CPU. The CPU must be in uppercase.

      The "__cpu" runtime model attribute is needed when producing
      COFF output. The compiler always supplies this attribute, so
      this error can only occur for programs consisting entirely of
      assembler modules. At least one of the assembler modules must
      supply this attribute.

4.51D

  124 Segment conflict for segment segment. In module "mod1" there
      is a segment part that is of type type1, while in module
      "mod2" there is a segment part that is of type type2

      All segment parts for a given segment must be of the same
      type. One reason for this conflict can be that a COMMON segment
      is mistakenly declared RSEG (relocatable) in one module.

      Another way this can happen is if COMMON and RELOCATABLE
      segments are given in the same -P segment placement command.

  123 The output format format does not support address translation
      (-M, -b# or -b@)

      Address translation is not supported for all output formats.

  122 The address address is too large to be represented in the
      output format format

      The chosen output format format cannot represent the address
      address. For example, the output format INTEL-STANDARD can
      only represent addresses in the range 0-FFFF.

  121 Segment part or absolute content at logical addresses start -
      end would be translated into more than one physical address
      range

      The current implementation of address translation does not allow
      logical addresses from one segment part (or the corresponding
      range for absolute parts from assembler code) to end up in more
      than one physical address range. If for example, -M0-1FFF=10000
      and -M2000-2FFF=20000 are used, it is not ok for a single
      segment part to straddle the boundary at address 2000.

  120 Overlapping address ranges for address translation. address
      type address address is in more than one range

      The address address (of type logical or physical) is the
      source or target of more than one address translation
      command. If, for example, both -M0-2FFF=1000 and
      -M2000-3FFF=8000 are given, this error may be given for any of
      the logical addresse in the range 2000-2FFF, for which two
      separate translation commands have been given.

  119 Cannot handle C++ identifiers in this output format

      The output format chosen is one that does not support the use of
      C++ identifiers (block-scoped names or names of C++ functions).

4.50A

  118 Incompatible runtime models. Module module1 specifies that
      attribute must be value, but module
      module2 specifies no value for this attribute

      These modules cannot be linked together. They were compiled with
      settings that resulted in incompatible runtime models.

  117 Incompatible runtime models. Module module1 specifies that
      attribute must be value1, but module
      module2 has the value value2

      These modules cannot be linked together. They were compiled with
      settings that resulted in incompatible runtime models.

  116 Definition of symbol in module module1 is not compatible with
      definition of symbol in module module2

      The symbol symbol has been tentatively defined in one or both
      of the modules. Tentative definitions must match other
      definitions.

4.49J

  115 Unmatched '"' in extended command file or XLINK_ENVPAR

      When parsing an extended command file or the environment
      variable XLINK_ENVPAR, XLINK found an unmatched quote
      character ('"'). For filenames with quote characters you need 
      to put a backslash before the quote character. For example, 
      writing

             c:\iar\"A file called \"file\""

      will cause XLINK to look for a file called

             A file called "file"

      in the c:\iar directory.

4.49F

  113 Corrupt input file: "symptom" in module module ( file )

      The input file indicated appears to be corrupt. This can occur
      either because for some reason the file has been corrupted after
      it was created, or because of a problem in the
      compiler/assembler used to create it. If the latter appears to
      be the case, please contact IAR.

4.49E

  112 The module module is for an unknown cpu (tid = tid). Either
      the file is corrupt or you need a later version of XLINK 

      The version of XLINK used has no knowledge of the cpu that the
      file was compiled/assembled for.

4.49C

  111 The file "file" is not a UBROF file                    

      The contents of the file are not in a format that XLINK can
      read.

  110 Function function mentioned as caller in -a# does not make
      indirect calls

      Only functions that actually make indirect calls can be
      specified to do so in an indirect call option.

  109 Function function mentioned as callee in -a# is not indirectly
      called

      Only functions that actually can be called indirectly can be
      specified to do so in an indirect call option.

  108 Cannot find function function mentioned in -a#

      All the functions specified in an indirect call option must
      exist in the linked program.

  107 Banked segments do not fit into the number of banks specified

      The linker did not manage to fit all of the contents of the
      banked segments into the banks given.

4.49A

  106 Syntax error or bad argument in option

      There was an error when parsing the command line argument given.

4.48K

  105 Recursion not allowed for this system. Check module map for
      recursive functions

      The runtime model used does not support recursion. Each function
      determined by the linker to be recursive is marked as such in
      the module map part of the linker list file.

4.48J

  104 Failed to fit all segments into specified ranges. Problem
      discovered in segment seg

      The packing algorithm used in the linker didn't manage to fit
      all the segments. Consider making smaller segment parts (moving
      things into different input files), or decreasing the total size
      of the segments, to make the packing easier.

  103 Ranges must be closed in option

      The '-P' option requires all memory ranges to have an end.

  102 No such segment type: option
      
      The segment type given is not a valid one.

  101 Segment already defined: "seg" in option

      The segment has already been mentioned in a segment definition
      option.

  100 Segment name too long: "seg" in option

      The segment name exceeded the maximum length (255 characters).

   99 Syntax error in segment definition: option

      There was a syntax error in the option.

   98 Unmatched /* comment in extended command file

      No matching '*/' was found in the .xcl-file.

   97 Unmatched -! comment in extended command line variable
      XLINK_ENVPAR

      As error 96, but for the environment variable XLINK_ENVPAR.

   96 Unmatched -! comment in extended command file

      An odd number of '-!' (comment) options were seen in an
      .xcl-file.

   95 Module mod ( file ) uses source file references, which are
      not available in UBROF 5 output

      This feature cannot be filtered out by the linker when producing
      UBROF 5 output. Use "-re" or "-ri" to the compiler to turn it
      off.

4.48G

   94 Unknown flag x in local symbols option -nx

      The character x is not a valid flag in the local symbols
      option.

   93 Non-existant warning number no, (valid numbers are 0-max)

      An attempt to suppress a warning that does not exist gives this
      error.

   92 Cannot use this format with this cpu

      Some formats need cpu-specific information and are only
      supported for some cpus.

   88 Wrong library used ( compiler version or memory model mismatch
      ). Problem found in mod ( file ). Correct library tag is
      tag

      Code from this compiler needs a matching library.  A library
      belonging to a later or earlier version of the compiler may have
      been used.

   87 Function with F-index i has not been defined before tiny_func
      referenced in module mod ( file )

      Check that all tiny functions are defined before they are used
      in a module.

   86 The definition for far/farc segment name can't be downwards or
      have a range
                                      
      Segments in far memory cannot be allocated from higher
      addresses, nor can they have a range given in the segment option
      -Z.

   85 The far/farc segment name in module mod ( file ), is
      larger than size

      The segment name is too large to be a far segment.

New warnings

5.3.0.22 - Introduced

   76 The checksum command checksum_command contains more than
      one specification of checksum unit size. You should use a single W
      or L flag.

The specified checksum command cannot have both a W and an L flag.

5.0.2.5 - Introduced
```
   75 The program does not contain any content. If this is not the intent
      use the content control linker options (-g and -s) or make content
      __root to ensure that it is included.
```
The link job resulted in a completely empty program. XLINK will remove all content that is not referenced and in this case there were no references to the program.
References can be specified on the command line through the -g option (for any symbol) or -s (for the start symbol of the program).
It is also possible to specify that a certain function or variable should always be present in the program by making it __root (in C with the IAR extensions enabled).
A program usually contains something (like an interrupt table) that is always included (made root or referenced through -g or -s) which in turns refers to the startup code which in turn refers to main which in turn refers to the rest of the program.

4.61S - Introduced
```
   74 The checksum polynomial polynomial is unsuitable for use
      with the bytewise initial value #initial value as the
      polynomial can not always generate a bitwise equivalent for the
      bytewise initial value. Use a bitwise initial value or use a
      polynomial with the least significant bit set.
```
The specified polynomial does not have its least significant bit set. When the least significant bit is not set it is not always possible to convert a bytewise initial value into a bitwise initial value. This has no real effect on the checksum that XLINK generates but it can matter in cases where the verification step uses bitwise initial values. As some bytewise initial values lack a corresponding bitwise initial value for this polynomial it can prove impossible to get the checksums to match.
4.61P - Introduced
```
   73 Total number of warnings for unsupported line numbers: number
      of warnings
```
This warning is tightly coupled to warning 72 (see below). It is mainly intended for the case that you have many (hundreds) functions that reside on line numbers that can't be represented in the chosen output format and do not want to list them all in every link job (so you suppress warning 72) but still want to know if the number of warnings change.
```
   72 The 'format' output format does not support line numbers above 
      number. All line numbers above this limit will be set to
      number. Source information for such functions will not be
      available. This will affect the following functions: list of
      function names, their segment part numbers, in which module and
      file they were defined
```
The chosen output format can not represent line numbers as great as the ones in the specified files. You have three options, choose a different output format, edit the source code file(s) so that no function that you wish to debug resides on line number above the specifed limit (move the function or split the file into two or more smaller files), or accept that you won't be able to debug the specified functions on the C-level (assembly level debugging and variable information will still be available).

4.61O - Introduced

   71 Use of the -! comment is deprecated. Recognition of -! will
      eventually be removed from XLINK.

Use "// comment" or "/* comment */" instead of "-! comment -!"

4.61L - Introduced
```
   70 The segment "segment" on address address overlaps
      previous content in the raw-binary output file. The previously
      content will be overwritten.
```
The program contains at least one overlap between segments with content. Use the overlap diagnostics to locate and correct those overlaps.

4.61I - Introduced
```
   69 Address translation (-M, -b# or -b@) has no effect on the output
      format 'format'.  The output file will be generated but
      no address translation will be performed.
```
Address translation is not supported for the format output format. Output files in the format output format will be generated without address translation but output files in a format for which address translation is supported will use translated addresses.

4.61G - Introduced
```
   68 The option to ignore overlaps in SFR-areas has been specified
      but the `processor` processor does not have an
      SFR-area. The option has no effect for this processor.
```
The processor you are using does not have a dedicated SFR-area (an address range in an address space that can only contain SFR:s). You can not use the -zs option to suppress segment overlap errors when using this processor.

4.61F - Updated
```
   23 limitation specific warning
```
Due to some limitation in the chosen output format, or in the debug information available, XLINK cannot produce correct debug output for this program. This only affects the debug information; the generated code remains the same as in an output format where the debug information can be expressed. Only one warning for each specific limitation is given.

4.61A - Updated
```
   20 The absolute segment on the address address range in the module
      module (file) overlaps the segment segment name 
      (from module module, address [address range])
```
An absolute segment overlaps a relocatable segment. You need to move either the absolute segment or the relocatable segment. You move absolute segments by modifying the source code. You move relocatable segments by modifying the segment placement command.
```
   21 The absolute segment on the address address range in the module
      module (file) overlaps the absolute segment on the address 
      address range in the module module (file)
```
Two absolute segments overlap. You need to move at least one of them. You move absolute segments by modifying the source code.

4.60D - Introduced
```
   67 Using "-r" causes XLINK to select modules that are adapted for
      use with the C-SPY debugger. This affects all output files, including
      those generated by -O.
```
The command line option -r has two effects. It causes XLINK to select modules from the IAR standard library designed to work with the IAR C-Spy debugger and makes XLINK use the IAR UBROF object format for its main output file. The first of these also changes the contents of any extra output files produced by the use of the -O command line option. Depending on the circumstances, this may not be what you want. If you need extra output files not meant for use with the IAR C-Spy debugger, you need to run XLINK separately, without the -r command line option.

4.60B - Introduced
```
   66 There is a gap between the addresses address and address. 
      This gap of gap size bytes will be padded with zeroes. Raw-binary 
      might not be the format you want for this particular image.
```
There is a huge "hole" in the image. This might result in an unnecessarily large file. A format that uses address records (like intel-extended, motorola or simple-code) might be a better choice for this particular image.

4.59U - Introduced
```
   65 There are both MULTWEAK and PUBWEAK definitions for the symbol named 
      "name". This does not work in the general case. PUBWEAK 
      definitions occur in the module(s) modules. MULTWEAK definitions 
      occur in the module(s) modules.
```
MULTWEAK definitions were introduced for purposes of ARM/Thumb Relay Function Optimization in ICCARM 3.41. PUBWEAK definitions were used for the same purposes in earlier versions of the ICCARM. In order to avoid this problem ensure that all modules are built for use with the same Relay Function model.
4.59R - Introduced
```
   64 The address space used in the command segment placement
      command is incompatible with the address space of the
      ranges 'ranges' that were inherited from previous
      placements. Address ranges can only be inherited from
      compatible address spaces.
```
Addresses should not be inherited from previous placement commands if those previous placement commands placed segments in an incompatible address space. This was sometimes used in older IAR tools to make sure that segments in placed in overlapping address spaces did not overlap each other. Since the introduction of the -U option in XLINK 4.56B that is no longer necessary, so inheriting from incompatible address spaces is now deprecated.

4.59L - Introduced

 
   63 No debug information will be generated for the function
      "function" in the module "module" as no debug
      information could be found.

This likely due to a rename entry operation in XLIB.

4.59K - Introduced
```
   62 The struct "name" is too large for the 'format'
      format, debug information will only be available for the
      first maxium size bytes.
```
The program contains a class/struct/union that is too large to represent in the chosen debug format. Debug information will be generated for as many bytes as the format can represent.
```
   61 The 'format' output format is not supported for this cpu.
```
Support for the chosen output format is experimental for this cpu.
```
   60 The entry point label "label" was not found in any input file
      The image will not have an entry point.
```
The chosen entry point label could not be found in any input file. Chose an entry point that exists in the program or make sure that that the file that contains the entry pointed is included in the input files.

4.56H - Introduced

    59 Too many COFF format line number records (number) needed. All 
       in excess of 65535 will not be accessible.

       There are too many line number records in one COFF
       section. This can cause a drastic loss of debugging usability
       if the number of records greatly exceeds 65535.

       One way to avoid this is to put code in more than one segment,
       as one COFF section is output for each segment.

       This problem is most likely to occur in the MPLAB debugger for
       the PIC processor, as one line number records is needed for
       each instruction in the code in that case.
    
    58 The name "name" was too long (more than number characters)
       and has been truncated to fit the chosen output format. 
       This warning is only issued once.  

       Normally, this will not affect debugging to any great extend,
       but if two or more long names are truncated to the same
       255-character string, a loss of debuggability may occur.

       The most common case where long names occur is when C++ names
       are flattened into simple strings, which occurs when
       translating into UBROF version 7 or older, or into other debug
       formats with a limit on symbol name length.

4.55G

   57 The file filename is empty and will be ignored.

      The file is completely empty (0 bytes). This is not a valid UBROF file
      but some IAR assemblers generate completely empty files instead of 
      a valid UBROF file with no content. This file will be ignored. If this
      file is not generated by an IAR assembler you should find out why the
      file is empty.

4.52A

   56 A long filename may cause MPLAB to fail to display the source
      file: 'pathname'

      When outputting COFF output for the PIC and PIC18 processors on
      a Windows host the output file contains a reference to a source
      file that needs long filenames in order to work. MPLAB cannot
      handle long filenames.

   55 No source level debug information will be generated for modules
      using the UBROF object format version 8 or earlier. One such
      module is module ( file )

      When generating UBROF 9 output, essential debug information is
      not present in input files using UBROF 8 or earlier. For these
      files all debug information will be suppressed in the output
      file.

4.51S
The warning about long filenames (warning 56) is warning 55 in XLINK 4.51S and XLINK 4.51T.

4.51E

   53 Some untranslated addresses overlap translation ranges. Example:
      Address addr1 (untranslated) conflicts with logical address
      addr2 (translated to addr1)

      This can be caused by something like this:

        -Z(CODE)SEG1=1000-1FFF
        -Z(CODE)SEG2=2000-2FFF
        -M(CODE)1000=2000

      This will place SEG1 at logical address 1000 and SEG2 at logical
      address 2000. However, the translation of logical address 1000
      to physical address 2000 and the absence of any translation for
      logical address 1000 will mean that in the output file, both
      SEG1 and SEG2 will appear at physical address 1000.

4.51D

   52 More than one definition for the byte at address address in
      common segment segment

      The most probable cause of this is that more than one module
      defines the same interrupt vector.

   51 Some source reference debug info was lost when translating to
      UBROF 5 (example: statements in "function" in module module)

      UBROF 6 file references can handle source code in more than one
      source file for a module. This is not possible in UBROF 5
      embedded source, so any references to files not included have
      been removed.

   50 There was a problem when trying to embed the source file "source"
      in the object file

      This warning is given if the file source could not be found or
      if there was an error reading from it. XLINK searches for source
      files in the same places it searches for object files, so
      including the directory where the source file is located in the
      XLINK include directories ("-I" command line option) could solve
      the first problem.

4.51A

   49 Using SFB/SFE in module module ( file ) for segment
      segment, which has no included segment parts

      SFB/SFE (assembler directives for getting the start or end of a
      segment) has been used on a segment for which no segment parts
      were included.

   48 Corrupt input file: "symptom" in module module ( file )

      The input file indicated appears to be corrupt. This warning is
      used in preference to Error 113 when the problem is not serious,
      and is unlikely to cause trouble.

4.50A

   47 Range error in module module ( file ), segment segment at
      address address. Value value, in tag tag, is out of bounds
      bounds

      This replaces error 18 when -Rw is specified.

   46 External function function in module module ( file ) has
      no global definition

      This replaces error 68.

   45 Memory attribute info mismatch between modules module1 (
      file1 ) and module2 ( file2 )

      The UBROF 7 memory attribute information in the given modules is
      not the same.

4.49E

   44 C library routine localtime failed. Timestamps will be wrong

      XLINK is unable to determine the correct time. This primarily
      affects the dates in the list file. This problem has been
      observed on one host platform if the date is after the year
      2038.

4.49C

   43 The function function in module module ( file ) is
      indirectly called but is not mentioned in the right part of any
      -a# declaration

      If any -a# indirect call options are given they must, taken
      together, specify the complete picture.

   41 The function function in module module ( file ) makes
      indirect calls but is not mentioned in the left part of any -a#
      declaration

      If any -a# indirect call options are given they must, taken
      together, specify the complete picture.

   40 The module module contains obsolete type information that will
      not be checked by the linker

      This kind of type information was replaced in 1988.

   39 The function function in module module ( file ) does not
      appear to be called. No static overlay area will be allocated
      for its params and locals

      As far as XLINK can tell, there are no callers for the function,
      so no space is needed for its params and locals. To make XLINK
      allocate space anyway use -a(function).

   38 There are indirect calls both from interrupts and from the main
      program. This can make the static overlay system
      unreliable. Using -ai will avoid this

      If a function is called from an interrupt while it is already
      running its params and locals will be overwritten.

   37 More than one interrupt function makes indirect calls. This can
      make the static overlay system unreliable. Using -ai will avoid
      this

      If a function is called from an interrupt while it is already
      running its params and locals will be overwritten.

   36 There are indirectly called functions doing indirect calls. This
      can make the static overlay system unreliable

      XLINK does not know what functions can call what functions in
      this case, which means that it cannot make sure static overlays
      are safe.

4.48J

   35 There is more than one definition for the struct/union type with
      tag tag

      Two or more different structure/union types with the same tag
      exist in the program. If these types were meant to be the same,
      it is likely that the declarations differ slightly. There will
      then also very likely be one or more warnings about type
      conflicts (warning 6). If they were not meant to be the same,
      consider turning off this warning.

   34 The 20 bit segmented variant of the INTEL EXTENDED format cannot
      represent the addresses specified. Consider using -Y1 (32 bit
      linear addressing).

      The program uses addresses higher than 0xFFFFF, and the
      segmented variant of the chosen format cannot handle this. The
      linear addressing variant can handle full 32 bit addresses.

   33 Using "-r" overrides format option. Using UBROF

      The "-r" option specifies UBROF format and C-SPY library
      modules. It overrides any "-F" (format) option

   32 Format option set more than once. Using format format

      The format option can only be given once. The linker uses the
      format format.

4.48G

   31 Modules have been compiled with possibly incompatible settings:
      more info

      According to the contents of the modules, they are not
      compatible.

   30 Module name is compiled for cpu1, expected cpu2

      You are building an executable for cpu cpu2, but module name
      is compiled for cpu cpu1.

   29 Parts of segment name are inited, even though it is of type
      type

      Initing DATA memory is not useful if the result of linking is to
      be promable.

   28 Parts of segment name are inited, parts not

      This is not useful if the result of linking is to be promable.

   27 No code at start address found in reset vector

      Failed in determining the LOCATION setting for XCOFF output
      format for the 78400 processor, because no code was found at the
      address specified in the reset vector.

   26 No reset vector found

      Failed in determining the LOCATION setting for XCOFF output
      format for the 78400 processor, because no reset vector was
      found.

   25 Using "-Y#" discards and distorts debug information. Use with
      care. If possible, find an updated debugger that can read modern
      UBROF

      Using the UBROF format modifier -Y# is not recommended.

   24 num counts of 'warning' total

      For each warning of type 23 actually emitted, a summary is
      provided at the end.

Log of minor changes

6.2.0.62 Logging (--log) - (Updated, stack_usage introduced)

New topic:

stack_usage

The stack usage at the point of call of the function.
The name of the function, or a single '-' to indicate usage in a function at a point with no function call (typically in a leaf function).
The stack usage along the deepest call chain from that point. If no such value could be calculated, "[---]" is output instead. "***" marks functions that have already been shown.

Example of log output:

    Program entry:
    0 __program_start [168]
      0 __cmain [168]
        0 __data_init [16]
          8 __zero_init [8]
            16 - [0]
          8 __copy_init [8]
            16 - [0]
        0 __low_level_init [0]
        0 main [168]
          8 printf [160]
            32 _PrintfTiny [136]
              88 _Prout [80]
                104 putchar [64]
                  120 __write [48]
                    120 __dwrite [48]
                      120 __sh_stdout [48]
                        144 __get_ttio [24]
                          168 __lookup_ttioh [0]
                      120 __sh_write [24]
                        144 - [0]
              88 __uidiv [0]
                88 __idiv0 [0]
              88 strlen [0]
         0 exit [8]
           0 _exit [8]
             0 __exit [8]
               0 __close_ttio [8]
                 8 __lookup_ttioh [0] ***
         0 __exit [8] ***

6.0.1.47 Weakly defined symbols (Introduced)
Starting with version 6.0.1.47 XLINK supports weakly defined symbols. Weakly defined symbols are defined using the normal -D option with =?= instead of =.
-Dsymbol=[?=]value
A weak definition is only chosen if no normal definition exists.
If a normal definition exists the weak one is just ignored.
-DFOO=42 and -DFOO=?=4711 results in FOO having the value 42, the weak definition is ignored.
If a weak definition is chosen it has the exact same effect as a normal definition.
The order of the options does not matter, a normal definition will always be chosen over a weak one.
6.0.0.46 NOALLOC content (Introduced)
Starting with version 6.0.0.46 XLINK supports NOALLOC content.
NOALLOC content is program content, typically string constants, that reside on the host rather than on the target processor. Such content can only be accessed through the debugger (or possibly something similar that can access the image and communicate with the program), it cannot be directly accessed by the program.
The primary purpose of NOALLOC is to allow the program to output string constants without storing them on the target, thus freeing up space there. NOALLOC requires support in the compiler/assembler, the linker and the debugger.
Generating NOALLOC content:
NOALLOC content is specified as such in the source code. The compiler/assembler treats NOALLOC content as normal content in most, but not all, ways. See the Compiler/Assembler reference manual for more information about this.
NOALLOC in XLINK:
- NOALLOC properties are already present in the input files. It is not possible to modify any NOALLOC property from XLINK.
- NOALLOC segments are not explicitly placed by a placement command. Each such segment is placed starting on address 0x0.
- NOALLOC segments are their own address spaces. A NOALLOC segment can never overlap other segments, regardless of if they are NOALLOC or not.
- NOALLOC segments, if present, are listed in a separate listing in the map file.
- NOALLOC segments are only output in output formats that supports them. Currently this only includes UBROF 11 and ELF/DWARF. If the output format does not support NOALLOC, such content will not be output in the image.
- Images that have been linked with NOALLOC content, but have had the NOALLOC parts removed (like output in a format that does not support NOALLOC) are quite likely to not work as expected.
Executing programs with NOALLOC content:
The debugger makes the NOALLOC parts of the executable image available to the program at runtime. Exactly how the debugger makes the content available is not specified. In the C-SPY debugger a plugin can request bytes on a specified offset in a NOALLOC segment. See the C-SPY reference manual for more information about this.
6.0.0.46 Logging (--log) - Introduced (no longer experimental)

--log {topic}[,topic[,topic[,topic]]]

--log_file file

topic

files, modules, segments

printf_scanf_selection

--log_file

Topics:

files

Example of log output:

     File  myObject.rXX =>
         C:\Users\TestUser\Documents\IAR Embedded Workbench\TestProject\Debug\Obj\myObject.rXX

modules

PROGRAM

LIBRARY

Example of log output:

     Loading program module c6x(c6x.rXX)
               weak def  :  CE
               weak def  :  CKCON (suppressed)
               definition:  ce_def
               definition:  ce_init
               reference :  CeCode
               reference :  stretch

c6x

c6x.rXX

CE

CKON

ce_def

ce_init

CeCode

stretch

segments

ROOT

The number in brackets at the beginning of each row is the depth of the reference tree. Level 0 entries are ROOT or referenced from the command line. An entry at a nonzero depth N is always referred to by the immediately preceding entry at depth N-1.
The reference depth is followed by one of these three:

A label, it is followed by text in [] that lists the segment part, the module and the name of the object file. The name of the object file is only output if it differs from the name of the module.
spXY describes segment part XY in the current module, it is followed by text in <> that contains one (there may be more than one) label in the listed segment part.
sfb/sfe(SEGMENT_NAME) describes references to the start/end of segment SEGMENT_NAME.

*** denotes previously listed entries. Their references will be ignored after the first listing.

Example of log output:

     Marking references from command line/config (?ABS_ENTRY_MOD)
     [0] __program_start [sp12 ?cstart(clCPUxsf.rXX)]
      [1] sp22 <?cstart_call_main>
       [2] main [sp28 ui_main]
        [3] sp4 <_A_WDTCTL_L>
        [3] sp24 <uiMainLcd>
         [4] sp24 <uiMainLcd> ***
         [4] back_check [sp12 lcd]
          [5] ?cstart_init_zero [sp15 ?cstart(clCPUxsf.rXX)]
           [6] __data16_memzero [sp4 ?memzero(clCPUxsf.rXX)]
            [7] sp4 <__data16_memzero> ***
           [6] sfb/sfe(DATA16_Z)
         [4] lcdTask [sp78 lcd]
          [5] sp12 <task_level>

The label __program_start

"-s __program_start"

__program_start

__program_start refers to sp22 which is the function ?cstart_call_main. It resides in the same module as its referrer. The reference depth 1 and the immediately preceding entry with reference depth 0 is __program_start, which resides in the module ?cstart.

sp22 refers to main, which is sp28 in the module ui_main.

main refers to sp4 (_A_WDTCTL_L) and sp24 (uiMainLcd) in the module ui_main.

sp24 refers to itself (it gets the *** mark). It also refers to back_check, which is sp12 in the module lcd.

back_check refers to ?cstart_init_zero which is sp15 in ?cstart.

?cstart_init_zero refers to __data16_memzero (which refers to itself) and it also refers the start or end of the segment DATA16_Z (zero initialized memory).

lcdTask is referred from sp24 (immediately preeceding entry with a depth 1 lower), it is sp78 in module lcd.

sp12 (task_level) is called from lcdTask. It does not make any references.

printf_scanf_selections

Example of log output:

     ### printf/scanf implementation selection
       _formatted_read:
         _large_read provides "assign_suppressions,floats,n_formatters,scansets"
         _medium_read provides "assign_suppressions,n_formatters,scansets"
         scanf establishes default "unknown"
         sscanf establishes default "unknown"
         util requires the feature set ""
         Final requirements: ""
         Best provider: _medium_read
       _formatted_write:
         _large_write provides "flags,floats,int_specials,n_formatters,qualifiers,widths"
         _medium_write provides "flags,int_specials,n_formatters,qualifiers,widths"
         _small_write provides "qualifiers"
         printf establishes default "unknown"
         sprintf establishes default "unknown"
         vprintf establishes default "unknown"
         vsprintf establishes default "unknown"
         teststuff has no requirement info but uses printf
          which requires the feature set "unknown"
         Final requirements: "unknown"
         Best provider: _large_write

_formatted_read

_large_read

_medium_read

For _formatted_write there are three suppliers, _large_write, _medium_write, _small_write. There are no requirements from the program but printf is used without supplying requirement information. This results in the default for printf (which is "unknown") being used. The final requirement is "unknown". The largest implementation, the one with the most features, _large_write, is chosen.

5.7.0.39 Threaded library (--threaded_lib) - Introduced
This option sets the system up for use with a threaded library. This requires that the library in question has been prepared for threaded use (see your manual for information about this).
The following redirections are made for C programs:
- __iar_Locksyslock to __iar_Locksyslock_mtx
- __iar_Unlocksyslock to __iar_Unlocksyslock_mtx
- __iar_Lockfilelock to __iar_Lockfilelock_mtx
- __iar_Unlockfilelock to __iar_Unlockfilelock_mtx
In addition, the following redirections are made for (E)C++ programs:
- __iar_Initdynamicfilelock to __iar_Initdynamicfilelock_mtx
- __iar_Dstdynamicfilelock to __iar_Dstdynamicfilelock_mtx
- __iar_Lockdynamicfilelock to __iar_Lockdynamicfilelock_mtx
- __iar_Unlockdynamicfilelock to __iar_Unlockdynamicfilelock_mtx
Finally the label __iar_Locksyslock_mtx is always included.

5.6.0.36 Forced noroot (-X) - Introduced
Starting with XLINK 5.6.0.36 the -X option offers a way to specify that all content in a file should be treated as if it had the NOROOT property. This option overrides any ROOT property the content of the specified files have.
This option can be useful if you have a library module that contains several entries that are ROOT (like interrupt functions) but you are only interested in some of the content in the module. Note that ignoring the root property on content quite easily can lead to the module behaving in unexpected ways, ROOT content usually have that property for a reason.
4.61Q - Forced root (-N) - Introduced
Starting with XLINK 4.61Q the -N option offers a way to specify that all content in a file should be treated as if it had the ROOT property (unreferenced ROOT-content is not removed by the linker).
Be aware that a module still needs to be referred to if it is to be kept. ROOT content in a non needed module will not be included in the program. Use -A myFile.rXX and -N myFile.rXX at the same time to make sure that all modules in the file are kept and that all content in the file is made ROOT.
4.61H - Overlap diagnostic control (-z) - Updated
Starting with XLINK 4.61H the -z option (treat segment overlaps as warnings) has 5 variants. These are:
```
    -z[a][b][o][p][s]
```
The default behavior is as if -zop has been specified, all overlaps are reported. In this case you can specify -zb and -zs to ignore overlaps, -zo and -zp have no effect.
The default behavior for the 8051 processor is as if -zbs had been specified, only overlaps that does not involve BIT-segments or SFR:s are reported. In this case you can specify -zo and -zp to report overlaps, -zb and -zs have no effect.
-za suppresses overlap errors between absolute entries. This is useful if you for instance have several absolutely placed variables on the same address. Note that -za only ignores overlaps where both entries are absolutely placed.
Use of the -zs option requires that the used processor has a dedicated SFR-area in XLINK. Currently, XLINK 4.61H (August 2008), the only processor that has a dedicated SFR-area is the 8051. Use of the -zs option for any other processor will generate warning 68 but otherwise have no effect.

4.61A - Updated -I option
Starting with XLINK 4.61A the argument of the -I option is no longer a semicolon separated list of path prefixes but a single additional include directory. This should have little impact on most existing .xcl-files.
If you used prefixes like -I..\MyPath\ or -IC:\MyData\MyProject\ nothing needs to be changed. All include paths generated by the IAR Embedded Workbench fall into this category.
If you used a semicolon separated list you need to split it so that each include directory gets its own option, -Iprefix1;prefix2;prefix3 becomes:
-Iprefix1
-Iprefix2
-Iprefix3
4.60A - Removed options
Starting with XLINK 4.60A the -t (Enable temporary file) and -m (Enable file bound processing) options are no longer recognized as options. The -t and -m options were available in older versions (4.50F and below) of XLINK to offer control over how files were read. Starting with XLINK 4.51A the options were still recognized but had no effect.
4.59E - Image input (--image_input)
The --image_input command line option is a way to link pure binary files in addition to usual input files.
The content of the file file is put into a segment part of the segment segment. The segment part defines the symbol symbol and has an alignment of alignment bytes.
The file's entire content is put into the segment so it can only contain pure binary data (like XLINK's new raw-binary output format).
The segment part is only included if symbol is referenced by the program, you can use the -g option (require symbols) to force a reference to the segment part.
Example:
The content of the pure binary file bootstrap.rXX is put into a segment part of the segment CSTARTUPCODE. The segment part will be 4-byte aligned and will only be included if the program (or the command line option -g) references the symbol Bootstrap.
4.58A - Specify entry point (-s)
The -s command line option adds a new way to specify the entry point for a program. If -s is used, the specified symbol will be used as the program entry point, and there must be a definition for the symbol in the program, or an Undefined External error (error 46) will be generated. This definition will also be included in the final link image.

Disable relay function optimization (-q)
When used with an ICCARM compiler version 4.10 or later, XLINK now performs Relay Function Optimization. Using -q will disable this optimization, retaining all used relay functions in the program. -q has no effect if there are no relay functions to optimize.

4.55F - Generate module summary (-xn)

The module summary summarizes the contributions to the total memory use from each module. Each segment type that is used gets a separate column, with one or two sub-columns for relocatable (Rel) and absolute (Abs) contributions to memory use.

Only modules with non-zero contributions are listed. Contributions from COMMON segments in a module are listed on a separate line, with the title + common Contributions for segment parts defined in more than one module and used in more than one module are listed for the module whose definition was chosen, with the title + shared.

    Module            CODE  DATA  CONST
    ------            ----  ----  -----
                      (Rel) (Rel) (Rel)
    ?CSTARTUP          152
    ?Fclose            308
    ?Fflush            228
    ?Fputc             156
    ?Free              252
    ?INITTAB                         8
    ?Malloc            348     8
    ?Memcpy             36
    ?Memset             28
    ?Putchar            28
    ?RESET
    + common             4
    ?Xfiles                  376   296
    + shared                        12
    ?Xfwprep           284
    ?Xgetmemchunk       96     1
    ?_EXIT              72
    ?__dbg_Break         4
    ?__exit             28
    ?close              36
    ?cppinit           100     4
    ?d__write           44
    ?div_module        100
    ?exit               20
    ?heap                            8
    ?low_level_init      8
    ?remove             36
    ?segment_init      120
    ?write              20
    atutor              88     4
    + shared                        12
    atutor2            364    40
                     -----   ---   ---
    Total:           2 960   433   336

4.55C - Absolute entries reported seperately
Absolute entries are no longer a part of the size total for each segment. Instead they are reported inside parentheses behind the total of the relocatable segment. An example might look like:
```
        296 bytes of CODE      memory (+ 2 absolute )
        768 bytes of DATA      memory
         24 bytes of CONST     memory
   
```
4.55B - Require global entries (-g)
XLINK normally only include segment parts (usually functions and variables) that are needed to meet all references from segment parts that must be included. This option is a way to add to this set so that something is included even if it appears not to be needed.
Include suppressed entries in the linker list file (-xi)
When i is specified XLINK includes all segment parts in a linked in module in the linker list file, not just the segment parts that were included in the output. This makes it possible to determine exactly which entries that were not needed.
4.51C - New default for intel extended
The INTEL-EXTENDED output format has been changed to use the 32-bit linear variant ("-Y1") by default on new targets. To get the 20-bit segmented variant for one of these targets use the format variant option "-Y0".

4.51A - Changes to the map file
The map file now includes information about segment type for addresses. On many processors this is used to determine the address space of an address (ie CODE/DATA on Harvard architectures).
To make place for this, two uninteresting columns have been removed from the Segment Map table in the map file.
Obsolete command line options
XLINK now ignores the command line options "-m" and "-t", if given. The new behavior is in essence as if "-m" was used, and "-t" was not used.
Extra space in segments
When using segment placement with extra space (eg CSTACK+100), the extra space is added only if there is at least one segment part actually included from this segment (ie, if the segment was actually needed for anything).

4.50A - Make range errors be warnings
The command line option -R has gained a flag, "w". As before, specifying -R makes XLINK ignore range errors. Now, specifying -Rw makes XLINK treat range errors as warnings.

4.49C - Maximum number of banks in -b
It is now possible to specify the number of banks in the bank segment placement option (-b). The syntax is now:
where the optional count is a decimal count of the number of banks available.

4.49A - No end address restriction for far segment placement
The restriction on address ranges for far segments has been removed. It is now allowed to have an end address (or even several ranges) in a "-Z" segment placement command line option dealing with far (FAR, FARCONST or FARCODE) segments.

4.49A - Downwards allocation end address changed to be more consistent
The meaning of a single address in a "-Z" option with downwards ("#") allocation has changed. It used to be that the address given was the first address not to be used. It is now considered to be the last address to be used. This is the same as when specifying a range.
Example:

4.48N - Turn off detailed type conflict information
A new command line option "-wt" has been added. When "-wt" is given the detailed type information output for warnings 6 (type conflict) and 35 (multiple structs with same tag) is suppressed.

4.48K - Return status control

A new command line option "-ws" has been added. It affects the return status of XLINK as follows:

    Condition                      No -ws      -ws
    ---------                      ------      ---
    No errors or warnings             0         0
    Warnings, but no errors           0         1
    One or more errors                2         2

"-ws" thus only affects the return status when there is one or more warnings but no errors.

4.48J - List output directory option
A new option "-L" is available. Its syntax is:
```
     -Lprefix          Generate a list on: <prefix> <dest> <.lst>
```
A useful special case of this is to use "-L" with no arguments to get a list file in the current directory.

4.48D - Suppress compiler generated module-local symbols
The -n option can now take a modifier 'c' to only suppress compiler generated module-local symbols. These are usually jump or constant labels, at best of fairly marginal interest, and even then only when debugging at assembly level. Example: