## Recent Manual Updates for XLINK V4.59N

Updated: Jun 20, 2005 [IJYB]
Archived: $Revision: 1.52 $

This document is a supplement to the XLINK Release Notes, xlink.htm, 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.51P]` IEEE-695 Details
`[4.59J]` XCOFF78K Details
`[4.59E]` Checksums and Fillers (-H -J -h)
`[4.59L]` Code Duplication (-K)
`[4.48J]` Pack Segments (-P)
`[4.56B]` Revised Segment Placement (-Z -P -b)
`[4.55B]` Expanded Segment Placement Range Syntax (-Z -P)
`[4.51A]` Function/Variable Level Linking
`[4.59G]` ELF details
`[4.51D]` Address Expressions
`[4.55B]` UBROF Versions
`[4.52B]` Address Translation (-M)
`[4.51J]` COFF Details
`[4.59K]` Scatter Loading (-Q)
`[4.51N]` Diagnostics Control (-w)
`[4.53A]` Multiple output files (-O)
`[4.55B]` Relocation areas (-V)
`[4.55F]` Range errors
`[4.56B]` Address space Sharing (-U)
`[4.59K]` MISRA C
`[4.59M]` New Errors
`[4.59L]` New Warnings
`[4.59E]` Log of Minor Changes

### Added Output Formats

When using the command line version of XLINK, the output format is selected with the -F command line option. In the Embedded Workbench it is selected on the XLINK Output Settings page.

#### 4.59E - Simple-Code

XLINK can now generate simple-code format output. Simple-code is a simple binary format that is primarily meant as a format for flash loading. It is available for all processors. See simple-code for more information about this format.

#### 4.59E - Raw-Binary

XLINK can now generate raw-binary fromat output. Raw-binary is a binary image format. It contains no header, no staring 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

XLINK can now generate three variants of the `motorola` output format, each using only a specific set of record types.

`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.

The `motorola` output format uses a mixture of the record types, depending on the range of addresses output.

#### 4.51J - COFF

XLINK can now generate COFF format output. See the COFF section of this document for more information about this format.

#### 4.51C - ELF

XLINK can now generate ELF format output with DWARF format debug information. See the ELF section of this document for more information about this format.

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

These three new output formats produce one output file in the IEEE-695 format and one in, respectively, the MOTOROLA, INTEL-STANDARD or INTEL-EXTENDED output format. If there is a need to supply format variant options for the second format, these can be added to the "-y" option after a comma.

Example:

    -Fieee695-ie -ygbr,1

This will output an IEEE-695 file using the format variant "-ygbr" and an INTEL-EXTENDED file using the format variant "-y1" (or "-Y1").

#### 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

The IAR Universal Binary Relocatable Object Format, UBROF, has been updated to version 8.0.0. This means that XLINK will now output UBROF 8 files when given UBROF 8 input. The UBROF format is used by IAR's C-SPY debugger and a number of other debuggers/emulators. The new version of the output format can, in addition to a number of other smaller improvements, result in a very significant reduction in the size of the output file.

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)

If you are using a debugger/emulator that reads UBROF and the output file cannot be loaded, a new format version could be the cause. In that case try using one of the -FubrofX variants or contact the supplier of your debugger/emulator. Also be sure to check the compiler release notes for any pertinent information on this issue.

#### 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.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.

- 4.48F - MSP430_TXT

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

### 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

  Output globally visible types in a BB2 block at the beginning of the output file.

      -yl  Output global types in each module

  Output the globally visible types in a BB1 block at the beginning of each module in the output file.

      -yb  Treat bit sections as byte sections

  XLINK supports the use of IEEE-695 'based variables' to represent bit variables, and the use of bit addresses for bit-addressable sections. Turning on this modifier makes XLINK treat these as if they were byte variables/sections.

      -ym  Adjust output for Mitsubishi PDB30 debugger

  Turning on this modifier adjusts the output in some particular ways for the Mitsubishi PDB30 debugger. Note that you will need to use the 'l' and 'b' modifiers as well (`-ylbm`).

      -ye  No block-local constants

  Using this modifier will cause XLINK to not emit any block-local constant in the output file. One way these can occur is if an enum is declared in a block.

      -yv  Handle variable life times

  Use the 'variable life time' support in IEEE-695 to output more accurate debug information for variables whose location varies.

      -ys  Output stack adjust records

  Output IEEE-695 'stack adjust' records to indicate the offset from the stack pointer of a virtual frame pointer.

      -ya  Output module locals in BB10 block

  Output information about module local symbols in BB10 (assembler level) blocks as well as in the BB3 (high level) blocks, if any.

      -yr  Last return refers to end of function

  Change the source line information for the last return statement in a function to refer to the last line of the function instead of the line it is on.

      -yd  No #define constants

  Do not emit any '`#define constant`' records. This can sometimes drastically reduce the size of the output file.

- 4.51P

  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
          T900     Toshiba RTE900 m25                 -ygbe
          T900     Toshiba RTE900 m15                 -ygbed

### XCOFF78K Details

- 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

  Symbols names longer than 31 characters will be truncated to be exactly 31 characters. Irrespective of the setting of this modifier, section names are always truncated to 7 characters if longer and module names are truncated to 31 characters.

      -yp  Strip source file paths

  Strip the path, if any, from source file references, leaving only the name and the extension.

      -ye  Include module enums

  Normally XLINK will not output module local constants in the xcoff78k file. The way IAR compilers currently work these include all `#define` constants as well as all SFRs. Turn on this modifier to get them included.

      -yl  Hobble line number info

  When outputting debug information, ignore any source file line number references that are not in a strictly increasing order within a function.

      -yn  Sort line numbers in ascending order

  Normally XLINK will output the debug information for each function in ascending address order. Some debuggers prefer to have the debug information in ascending line number order instead. Turn on this modifier to make XLINK produce debug information that is sorted in ascending line number order.

### Checksums and Fillers (-H -J -h)

- 4.59E - Arbitrary number of checksum commands XLINK can now generate an arbitrary number of checksums, each of which can be for any specified ranges of memory.

      -Jsize,algo{,flags{,sym{,seg{,align}}}}{=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
         ranges        Calculate checksum from bytes in ranges

  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:

      -Jsize,algorithm[,flags]

  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:

      -J4,crc32,1

  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:

      -h[()]{}+

  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:

      -h(CODE)0-FFFF

  or, equivalently, as segment type CODE is the default,

      -h0-FFFF

  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.

### Code Duplication (-K)

- 4.59L - Updated

      -Ksegments={-}increment,count

  Starting with XLINK 4.59L it possible to specify negative increments to the -K option. Negative addresses and addresses above 0xFFFFFFFF are not allowed.

  Example:

      -KMYSEG=-0x2000,4

  If MYSEG is placed at 0x10000, this will create 4 duplicates placed at 0xE000, 0xC000, 0xA000 and 0x8000.

- 4.49C - A new option to do code duplication has been added:

      -Ksegments=increment,count

  Duplicate any raw data bytes from the segments `count' times, adding increment to the addresses each time. In order for this to be useful, the segments should likely be mentioned in a "-Z" segment placement option. The count can optionally be specified as '*', which means to duplicate the segments enough times to match the highest number of banks actually used in a bank segment placement option.

  This can be used to make part of a PROM be non-banked even though the entire PROM is physically banked. Use "-b" or "-P" to place the banked segments into the rest of the PROM.

  Example:

      -KRCODE0,RCODE1=20000,4

  Duplicate the contents of the RCODE0 and RCODE1 segments 4 times, using addresses 0x20000 higher each time. This will place 5 copies of each of the bytes from the segments into the output file, at the addresses x, x+0x20000, x+0x40000, x+0x60000 and x+0x80000.

### Pack Segments (-P)

- 4.48J

  A new option "-P" is available, as a complement to "-Z" (segment definition) and "-b" (banked segment definition). It has the syntax:

      -P[(type)]segments=start-end[,start-end]...

  The linker attempts to pack the segment parts from the segments given in a "-P" option into the ranges given. In order to do this it splits each segment into its segment parts and forms new segments for each of the ranges. All the ranges have to be closed (have both a start and an end). The segment parts will not be placed in any specific order into the ranges.

  A segment part is the smallest linkable unit. Prior to UBROF 7 each module could have at most one segment part for a particular segment. Beginning with UBROF 7 a module can make several separate contributions to a segment.

  Attempting to get the start and end (using the SFB/SFE assembler operators) of a segment that has been split and reformed will not work.

### Revised Segment Placement

- 4.56B - SPLIT-

  When doing sequential segment placement (-Z), it is now possible to specify that the segment or segments may be placed non-contiguously. Normally, when doing sequential segment placement, each segment is placed in its entirety into one of the address ranges specified, but when SPLIT- is specified, each segment part is placed separately, in sequence, allowing a segment to straddle one or more gaps between address ranges.

  Example: `-Z(SPLIT-CONST)DATA_Z=4000-7FFF,8000-BFFF`

  Assume that at the moment of placement, addresses 4000-7003 have been reserved for other purposes. If the DATA_Z segment consists of 100 segment parts, each 50 bytes long, the entire DATA_ID segment does not fit into the the range 7004-7FFF, which would, if SPLIT- was not specified, cause XLINK to place the segment starting at address 8000. As SPLIT- is specified, the first 81 segment parts would be placed sequentially from address 7004, and the remaining 19 from address 8000.

  This is relatively rarely useful. The only case where this kind of placement is better than packed placement (-P) is when the start and end of the segment are significant, like when the entire segment needs to be zeroed at program startup, and individual segment parts cannot be placed at arbitrary addresses (in the example above, no segment part can straddle the address 8000).

  The result of SPLIT- is similar to the effect of using sequential segment placement with one of the far segment types (FARCODE, FARCONST, FARDATA). There are two differences: 1) Using a far segment type implicitly divides the address ranges given into 64K byte sections (similarly to what would happen if the range had been written `[start-end]/10000`). 2) SPLIT- can be used with any address space, while a far segment type can only be used with the address spaces denoted by the segment types CODE, CONST and DATA.

- 4.55B - Relocation Areas

  Segments can now be placed relative to relocation areas. See Relocation areas (-V) for details on relocation areas.

- 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.

### Expanded Segment Placement Range Syntax

- 4.55B - Added :+

  Ranges can now be defined using the syntax `[start:+size]` , as well as `[start-end]` Thus, `[1000:+1000]` is the same as `[1000-1FFF]` and `[1000:+1000]*3+2000` is the same as `1000-1FFF,3000-3FFF,5000-5FFF`

- 4.51A - Introduced

  The syntax for address ranges in the -Z and -P segment placement command line options has been extended to make it more convenient to specify repeating ranges.

  1. Ranges with a repeat count

         [SSS-EEE]*NNN+XXX

     This repeats the range SSS-EEE NNN times, adding XXX each repition. The +XXX part is optional, and defaults to the length of the range. For example:

         [1000-1FFF]*3+2000

     is the same as

         1000-1FFF,3000-3FFF,5000-5FFF

     and

         [1000-1FFF]*3

     is the same as

         1000-1FFF,2000-2FFF,3000-3FFF

  2. Paged ranges

         [SSS-EEE]/PPP

     This is the entire range SSS-EEE, split into pages of size and alignment PPP. For example:

         [50-77F]/200

     is the same as

         50-1FF,200-3FF,400-5FF,600-77F

     Note that the start and end of the range do not have to coincide with a page boundary.

  All numbers in segment placement command line options are interpreted as hexadecimal unless preceded by a '.'. That is, the numbers written as "10" and by ".16" both mean the number sixteen.

### Function/Variable Level Linking

- 4.51A

  Linking now takes place in two steps. XLINK first does module level linking and then segment part level linking.

  Compilers/assemblers producing UBROF 7 or later can put individual functions/variables into separate segment parts, and can represent all dependencies between segment parts in the object file. This enables XLINK to exclude unneeded functions/variables from a build. Object files in UBROF 6 or earlier cannot represent this information and thus do not take advantage of the new feature.

  Module level linking starts by including all PROGRAM modules. Then enough LIBRARY modules are included so as to satisfy all external symbol references, if possible. When more than one LIBRARY module exports a certain symbol, preference is given to the module that is specified first on the command line.

  Segment part level linking then starts by including all ROOT segment parts in included modules, and then adds enough other segment parts to satisfy all dependencies. Dependencies are either references to external symbols defined in other modules or intra-module segment part references. ROOT segment parts are normally the root of the C runtime boot process and any interrupt vector elements.

### ELF details

- 4.59G - Format Variant Modifiers - Updated

  The available format variant modifiers for ELF/DWARF are:

      -ya  Format suitable for debuggers from ARM Ltd (also sets -p flag)

  Adjusts the output to suit ARM Ltd debuggers. This changes the flag values for some debug sections in ELF and pads all sections to an even multiple of four bytes. It also has the effect of turning on -yp.

      -yc  Use address_class attributes for pointer types

  Output an address_class attribute for pointer types based on the UBROF memory attribute number. Use of this format variant option requires a DWARF reader (debugger) that understands these.

      -yf  Suppress DWARF Call Frame Information

  Do not output a .debug_frame section. Note that a .debug_frame section is only generated if enough information is present in the linker input files.

      -ym  Output types in each compilation unit, instead of once for all

  Normally, all types are output once, in the first compilation unit, and global debug info references are used to refer to them in the rest of the debug information. If -ym is specified, all types are output in each compilation unit, and compilation unit relative references are used to refer to them.

      -yn  Suppress DWARF debug output

  Output an ELF file with no debug information.

      -yp  Multiple Elf program sections

  Output one Elf program section for each segment, instead of one for all segments combined.

      -ys  Ref_addr (global refs) use .debug_info (not file) offsets

  If -ys is not used, global debug info references (used for references to type records when -ym is not specified) are offsets from the start of the ELF file. Specifying -ys causes XLINK to use offsets from the start of the .debug_info section instead. The latter is the more common usage.

      -yv  Use variant use_location semantics for member pointers

  The DWARF standard specifies a use_location semantics that requires passing complete objects on the DWARF expression stack, which is ill-defined. Turning on this option causes XLINK to emit use_location attributes where the addresses of the objects are passed instead. Use of this format variant option requires a DWARF reader (debugger) that understands this.

      -yr  Produce a relocatable executable ELF file

  When this option is specified XLINK produces a relocatable executable ELF file. Relocatable executable means that xlink will produce a file that is both executable (like XLINK's normal ELF files) but also contains relocation directives to make it possible to execute the image at an address other than that at which it was linked.

  To be able to produce relocatable executable files you need a compiler that supports relocation (consult your manual if you are not sure of this) and a 4.55B or higher version of XLINK.

  To be able to use relocatable output you also need an ELF-reader capable of reading relocatable ELF files and place them in memory.

      -yx Strip source file paths, leaving only the file name and extension

  This options strips the path of all source file references so the reference is only a file name, C:\MySource\MyProject\MyFile.c and /home/myuser/mysource/myproject/MyFile.c would both become references to MyFile.c.

  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.

- 4.55D - Recommended settings for some CPUs and debuggers are:

             ARM     Any ELF/DWARF debugger            -yas
             M32C    Mitsubishi KD30                   -yspc
             M16C    Mitsubishi PD30                   -yspc

- 4.51I - Format Version

  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.

- 4.55D - Supported Targets

  The ELF format is currently supported for the 6811, 6812, 6816, Arm, M16C, MC80, M32C, SH and v850 target processors.

### Address Expressions

- 4.51D - Symbolic Addresses

  Addresses in command line options can now use symbolic values defined in earlier "-D" command line options. If the symbol can be confused with a (hexadecimal) number it must be enclosed in quote ("'") characters. Example:

           -Dfoo=1000
           -Dfee=1FFF
           -Z(CODE)CODE=foo-'fee'

  The last line is equivalent to:

      -Z(CODE)CODE=1000-1FFF

  Note that the symbol "fee" must be quoted since "fee" is a legal hexadecimal number.

- 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:

      -Z(CODE)CODE=1000-1FFF

### 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.

- 4.55B - Brief History

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

           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

- 4.53D - Supported Versions

  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

  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.

  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.52B

  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:

      -M[(segment_type)]logical_ranges=physical_ranges

  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:

      -M0-FF,200-3FF=1000-11FF,1400-14FF

  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

- 4.51J - Supported Targets

  XLINK currently supports COFF output for the PIC target processor, tailored to work with the MPLAB debugger. MPLAB needs both an intel-hex file and a COD file. To convert the file from COFF to COD use the MP2COD program supplied in the Microchip MPLAB distribution.

  The way to use COFF output for Microchip MPLAB is to use the option `-Fcoff` to set the primary output format, and then add the option `-Ointel-standard=.hex` (or intel-extended) to the linker file to generate both formats at the same time.

  The ICCPIC linker files has the -O option added to produce intel-hex files by default.

  XLINK does not support debug info for include files, and for assembler files with multiple modules, may generate multiple instances of the source files in the absolute listing file produced by MP2COD.

  XLINK also generates a varying number of dummy files that will generate a warning from MP2COD that it cannot find the file specified. All these files have names beginning with $$. The warnings can safely be ignored.

### 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:

      -Qsegment=initializer_segment

  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:

      -QRAMCODE=ROMCODE

  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)

- 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:

      -w<ID>[=<severity>]

  `<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

### Multiple output files (-O)

- 4.53A - Multiple output files

      -Oformat[,variant][=filename]

  Any number of `-O` command line options can be specified. Each will result in one output file using the format format, possibly with the variant variant (as if specified in a `-Y` or `-y` command line option). If no filename is given, the output file will get the same name as some other output file, or the name given in a `-o` command line option, with the default extension for the format. If the filename starts with a '`.`', it is assumed to be an extension, and the file gets the same name as if no name was given, only with the specified extension.

  Example:

      -Odebug=foo
      -Omotorola=.s19
      -Ointel-extended,1=abs.x

  This will result in one output file named `foo.dbg`, using the UBROF format, one named `foo.s19`, using the MOTOROLA format, and one named `abs.x`, using the INTEL-EXTENDED format as if `-Y1` was also given.

  Output files produced by using -O will be in addition to those produced from use of the -F/-o/-y command line options. This means that until support for the new feature is added to the Embedded Workbench, extra output files can be added to the linker command file.

  As before, if `-r` is specified, only one output file is generated, using the UBROF format and selecting special runtime library modules for C-SPY.

- 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:

      -Ointel-extended,(CODE)=file1
      -Ointel-extended,(DATA)=file2

  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)

- 4.55B - Introduced

  Relocation areas are a way to partition the set of segments in such a way that a loader can place them in different parts of memory. Each relocation area has a start address that is assigned a value at load time.

  Normally, when not producing relocatable output, XLINK assigns addresses to all symbols and segment parts. When producing relocatable output, each symbol and segment part can instead be assigned an offset from the start of a Relocation Area. This is then turned into a regular address at load time, when the loader determines the location of each Relocation Area. Relocation areas are created using:

      -V(segment type)Relocation Area name[,align]

  Segment type is the same as used in segment placement commands (-Z, -P), and will be used for segments placed into this Relocation Area.

  Align is the minimum power of two alignment of the Relocation Area. For instance, a value of 2 means that the Relocation Area will always be placed at an address that is an even multiple of 4 bytes. This value must at the very least be as high as that of any segment that will be placed into the Relocation Area.

  Relocation areas can be used instead of segment types in segment placement commands (-Z, -P).

  Mixing segment placement using Relocation areas with segment placement using segment types will result in an executable file where parts are relocatable, and parts are absolute. This is likely to not be very useful.

  An example: ``

         // Declare three Relocation areas for code, constants and data.
         -V(CODE)CODE_AREA,12
         -V(CONST)CONST_AREA,12
         -V(DATA)DATA_AREA,12

         // Place segments into the Relocation areas
         -Z(CODE_AREA)RCODE,CODE=0-FFFFFF
         -Z(CONST_AREA)DATA_C,DATA_ID=0-FFFFFF
         -Z(DATA_AREA)DATA_Z,DATA_I=0-FFFFFF

### 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?

Some instructions do not work unless a certain condition holds after linking, examples include that a branch target must be within a certain distance or that an address must be even. The compiler/assembler generates tests and XLINK verifies that the conditions hold when the files are linked. If a condition is not satisfied XLINK generates a range error or warning and prints a description of the error.

#### Range error example

This example was taken from an ARM project.

        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

The first section is often the most important. The part after "Range error," is generated by the compiler/assembler and is a description of what is being tested. In this case the test is if the target of a branch instruction is in range.

##### Where

This is the location of the instruction that caused the range error. $, the address of the instruction, is `0x804c`, or `0xC` bytes after the label `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:

This is the symbolic expression that XLINK evaluated and the value it resulted in. In this case XLINK performs the calculation `0x8673450 - (0x804C + 8)` and gets the result `0x866B3FC`.

##### Allowed range:

This is the range that the computed value must fall within for a range error not to occur. If the left hand side of the expression is greater than the right hand side it should be interpreted as a negative value. In this case the range is `-0x2000004 - 0x2000000` and represents the reach of the ARM branch and link instruction.

##### Operand:

Each symbolic operand in the expression is described in detail here. The format used is the same as in the definition of $.

##### Possible solutions

In this case the distance from the instruction in vectorSubtraction to vectorNormalization is too great for the branch instruction.

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

If some bytes are placed in CODE at address 1000, the corresponding bytes in DATA will be reserved, but not the ones in CONST. The work-around is to specify the third ("missing") address space sharing:

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

### 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 Errors

- 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

- 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.

         23 limitation specific warning

            Due to some limitation in the chosen output format, or in the
            information available, XLINK cannot produce the correct
            output. Only one warning for each specific limitation is given.

### Log of Minor Changes

- 4.59E - Image input (--image_input)

      --image_input=file,symbol,segment,alignment

  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:

      --image_input=bootstrap.rXX,Bootstrap,CSTARTUPCODE,4

  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)

      -s symbol

  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)

      -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)

      -gsymbol1[,symbol2,symbol3,...]

  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)

      -x{smeohi}

  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:

      -b[addrtype][(type)]segments=first,length,incr[,count]

  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:

           -Z(CODE)CODE#5000

  This used to mean the same as

           -Z(CODE)CODE#0-4FFF

  but is now the same as

           -Z(CODE)CODE#0-5000

- 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:

      -nc

Copyright 2005 IAR Systems. All rights reserved.