## Readme file for the IAR XLINK Linker V4.59N

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

- Important information
- Manual Corrections and Updates
- The XAR Library Builder
- Known problems in Current Version
- Program Corrections and Updates

### Important information

#### XLINK 4.55H - 2003-05-13

- EW14006 In segment placement commands, when using consecutive ranges (like 0-FF,100-1FF,200-2FF or, equivalently, [0-2FF]/100), XLINK treated the range as if it was 0-2FF without the boundaries. Segments that were too large for the original ranges would fit and segments could be placed across boundaries that they should not be allowed to be placed across.

  This problem was introduced in XLINK 4.55B.

#### XLINK 4.55B - 2002-12-17

- The IAR Universal Binary Relocatable Object Format, UBROF, has been updated to version 10.0.0. This means that XLINK will now output UBROF 10 files when given UBROF 10 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 supports C++ templates, has no limit on the number of segments and externals in a module and has no limit on the number of types in a program.

  XLIB supports UBROF 10 starting with version 3.28N.

  All released versions of XAR support UBROF 10.

  XLINK is now able to produce relocatable output, output that can be located after linking by a program loader. This is currently only supported for the ARM processor and the ELF output format.

#### XLINK 4.53J - 2002-03-18

- XAR, the IAR Universal Library Builder, is now included in the XLINK package. XAR has a very simple command line interface to construct library files from object files, which is likely to be far more convenient than using XLIB for the same purpose.

#### XLINK 4.53I - 2002-02-19

- XLINK calculated the wrong value for SFE (Segment End) directives for segments placed using far placement when the entire segment did not fit in a single 64K page. The incorrect value was too low by the amount of space skipped at the page boundaries.

  Initialization of variables in far memory normally uses the SFE (or equivalently, SIZEOF) directive to determine the amount of data to set. This means that the incorrect value can result in some bytes of initialized or zeroed variables in far memory not being set at program start-up.

  This problem was introduced in XLINK version 4.52E, released 2001-02-19.

#### XLINK 4.53A - 2001-06-07

- The IAR Universal Binary Relocatable Object Format, UBROF, has been updated to version 9.1.0. This version supercedes UBROF 9.0.0, for which version support has been dropped from XLINK.

  XLIB supports UBROF 9.1 starting with version 3.28B.

#### XLINK 4.52A - 2000-10-20

- The IAR Universal Binary Relocatable Object Format, UBROF, has been updated to version 9.0.0. This means that XLINK will now output UBROF 9 files when given UBROF 9 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 improves debug information support. Specifically it adds support for call frame information and better statement information.

  This adds a new output format to XLINK:

      -Fubrof9   Output UBROF 9 even if no input was UBROF 9

  As before, using -r or -Fdebug will produce output using the latest version of UBROF used in any of the input files.

  If you are using a debugger/emulator other than C-SPY that reads UBROF and a compiler generating UBROF 9 (check the documentation accompanying the compiler) and the output file cannot be loaded, the new format version could be the cause. In that case try using -Fubrof8/-Fubrof7/-Fubrof6/-Fubrof5 or contact the supplier of your debugger/emulator. Also be sure to check the compiler release notes for any pertinent information on this issue. As of this writing only one IAR compiler generates UBROF 9 output.

  XLIB supports UBROF 9 starting with version 3.28A.

- Starting with version 4.52A, the Windows release of XLINK is no longer delivered with a DOS extender. This means that XLINK will not work in environments that do not provide the Win32 interface (Win32 is provided in Windows 95 and later).

  The same is true for XLIB, starting with version 3.28A.

#### XLINK 4.51D - 1998-12-01

- 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 adds support for Embedded C++.

  This adds a new output format to XLINK:

      -Fubrof8   Output UBROF 8 even if no input was UBROF 8

  As before, using -r or -Fdebug will produce output using the latest version of UBROF used in any of the input files.

  If you are using a debugger/emulator other than C-SPY that reads UBROF and a compiler generating UBROF 8 (check the documentation accompanying the compiler) and the output file cannot be loaded, the new format version could be the cause. In that case try using -Fubrof7/-Fubrof6/-Fubrof5 or contact the supplier of your debugger/emulator. Also be sure to check the compiler release notes for any pertinent information on this issue. As of this writing only IAR compilers capable of compiling C++ generate UBROF 8 output.

#### XLINK 4.51C - 1998-10-21

- XLINK can now generate ELF format output with DWARF format debug information. See XMAN.HTM for details.

#### XLINK 4.51A - 1998-10-08

- Segment placement has been improved. See XMAN.HTM for details.

#### XLINK 4.50C - 1998-05-14

- The IAR Universal Binary Relocatable Object Format, UBROF, has been updated to version 7.0.0. This means that XLINK will now output UBROF 7 files when given UBROF 7 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 exists mainly to expand the system for keeping track of IAR specific type and object attributes.

  This adds a new output format to XLINK:

      -Fubrof7   Output UBROF 7 even if no input was UBROF 7

  As before, using -r or -Fdebug will produce output using the latest version of UBROF used in any of the input files.

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

### Known problems in Current Version

#### XLINK 4.59N - 2005-06-20

- EW10551: [XLINK0151] SFRs are not present in the IEEE-695 output from XLINK for code compiled with compilers using UBROF 6 and earlier.

- EW10554: [XLINK0119] When doing static overlay, XLINK fails to warn about functions called from indirect functions and from someplace else. This is dangerous, if, for instance, one of these is from an interrupt function and the other from main.

- EW10555: [XLINK0116] Under certain circumstances XLINK can fail to place empty segments. This will happen if the entire memory address range in which to place the empty segments has already been taken by previous segment placements, or by absolute code from assembler modules, but the address (not the byte) after the range is still free.

- EW10556: [XLINK0107] Empty segments placed in previous segment placement commands do not cause later segment placements ranges to split. Example: -ZEMPTY=400-4FF -ZBAR=0-FFFF. This should place the empty segment EMPTY at address 400 and cause the range 0-FFFF to be split into 0-3FF and 400-FFFF.

- EW10557: [XLINK0045] Static overlay system: A function which does not appear to be called (warning 39) still counts as a caller for warning 16 (function called from two function trees), resulting in two warnings instead of one.

- EW10558: [XLINK0136] Specifying filler ranges explicitly (using -h) does not work if any segment parts are placed using banked placement (-b). Use packed placement (-P) instead.

### Program Corrections and Updates

#### XLINK 4.59N - 2005-06-20

- EW16836 Previous versions of XLINK have always set the stack usage of all functions to 0 in the xcoff78k format as sufficient stack usage information have not been available in the input files. Now the stack usage will be set correctly provided that the stack usage information is present in the input files (ICC78000 v4 supplies the needed information).

- EW16896 When performing ARM/Thumb Relay Function Optimization and using sequential segment placement (-Z) for the segment containing the code, XLINK could terminate with an internal error in rare circumstances involving intra module mode switching calls to a non inlined function in an interwork module. This problem was introduced in XLINK 4.58B.

#### XLINK 4.59M - 2005-05-16

- EW16744 When an expression ( (START-END) ) resulting in a negative number was used as a range declaration, XLINK terminated with an internal error. Note that START-END is a range while (START-END) is an expression. Negative start ranges now generate error 156.

- EW16751 When generating the linker list file for a case where two or more segments had been placed with -P (packed segment placement) in the same memory range using different segment types (example: -P(CODE)CODESEG=1000-2FFFF -P(CONST)CONSTSEG=1000-2FFFF), the end of the resulting packed segment in the segment map (-xs) could be incorrect. This problem has been present in XLINK since 4.59K.

- EW16799 Xlib has been updated to handle completely empty (0 byte) UBROF files. Completely empty files can be produced by some IAR assemblers under special circumstances.

- EW16811 When generating the entry list of the linker list file, all function and block scope locals were always listed as residing in the CODE address space. This problem has been present in XLINK since XLINK 4.55B.

- EW16823 When performing ARM/Thumb Relay Function Optimization, XLINK could terminate with an internal error ("address calculation needed to use an invalid address") if there were several non inlined instances of an inlined function where at least one instance was compiled in arm mode and at least one instance was compiled in thumb mode. This was a variant of EW16612. This problem has been present in XLINK since the introduction of Relay Function Optimization in XLINK 4.58A.

- EW16832 When producing the module summary part of the linker list file (-xn), the total size of the module's contribution to common segments was incorrect when the module contained more than one common segment part with the same name. The problem only affected the contribution from modules, the listed total size of the common segments in the program was correct This problem has been present in XLINK since the introduction of -xn in 4.55F.

- EW16833 When performing ARM/Thumb Relay Function Optimization with code using relay functions in several different segments and some of the segments were placed far (> 4.2 MB) apart, XLINK could fail to generate relay functions correctly, resulting in a range error.

- EW16835 When performing ARM/Thumb Relay Function Optimization and the program would not fit in the allocated ranges even if all relay functions were eliminated, XLINK could give error 144 (unable to use definition of last resort) instead of error 15 (segment too long).

#### XLINK 4.59L - 2005-04-15

- EW16597 When producing IEEE695 output, XLINK could terminate with an internal error if the program contained any long long c-type.

- EW16612 When performing ARM/Thumb Relay Function Optimization, XLINK could terminate with an internal error ("address calculation needed to use an invalid address") if there were several non inlined instances of an inlined function where at least one instance was compiled in arm mode and at least one instance was compiled in thumb mode. This problem has been present in XLINK since the introduction of Relay Function Optimization in XLINK 4.58A.

- EW16633 When doing segment duplication (-K), XLINK could terminate with an internal error if the increment was so large that the address of at least one duplicated segment would become greater than 0xFFFFFFFF. This now generates error 154. When using -K it is now possible to specify negative increments. See the -K option for the details.

- EW16625 When an empty option (example: xlink -f lnkXX.xcl file.rXX "" ) was encountered, XLINK terminated with an internal error. Some versions of the Embedded Workbench send "" to XLINK. This problem was introduced in XLINK 4.59K.

- EW16654 When generating error 142 (Entries included in PUBWEAK/PUBLIC resolution must be in a named segment), the PUBLIC and PUBWEAK labels were switched so the PUBLIC label was listed as PUBWEAK and the PUBWEAK label was listed as PUBLIC. This problem has been present since the introduction of error 142 in XLINK 4.56F.

- EW16692 When generating output in the XCOFF78K format, XLINK terminated with an internal error if at least one object file contained a symbol that had been renamed using XLIB's rename-entry command, this can only happen for files using UBROF 7 or earlier and contain debug information. This now generates warning 63.

- EW16734 When performing ARM/Thumb Relay Function Optimization, XLINK could terminate with an internal error ("address calculation needed to use an invalid address"). This could happen if a globally visible thumb function that was removed by XLINK (not used by the program) and used the _BLF pseudo instruction for calls inside the module (this usually only happens when --interwork is used). This problem has been present in XLINK since the introduction of Relay Function Optimization in XLINK 4.58A.

- The "banked" / "non banked" function property in the module map of the linker list file has been removed as it is deemed to be obsolete.

- XLINK now supports asm mode change information. This allows better disassembly of code and data for toolsets that support generation of such information.

- UBROFRecordTags.pdf is now included in the XLINK distribution. This document describes which record types in a UBROF file can affect the actual application code, and which record types only give supplementary information used for debugging or other purposes.

#### XLINK 4.59K - 2005-03-08

- EW16172 When generating multiple output files (-O), XLINK can now create the output file using a relative path. Example: -Oelf,as=..\MyElfCode\myApp.elf

- EW16386 When generating output in the xcoff78k format, XLINK terminated with an internal error if a struct type was larger than 65535 bytes. Xcoff78k can only represent debug information for struct types of sizes up to 65535 bytes, larger struct types will now get their size set to 65535 bytes. XLINK will generate warning 62 when this happens.

- EW16476 When producing output in the xcoff78k format, XLINK could terminate with an internal error if the input files contained absolutely placed variables with the __const memory attribute and were compiled using the ICC78K v4 compiler.

- EW16557 When linking files that contained the program entry point in a region introduced using the ASEG assembler directive, XLINK terminated with an internal error.

- EW16566 When doing function auto storage layout for processors that use the static overlay system, XLINK could fail to correctly allocate memory for a function's parameters and local storage. This could happen when a program had multiple non inlined instances of an inlined function (or contained assembler code that used multiple PUBWEAK symbols in a similar way). This problem could result in an incorrect program and has been present in XLINK since the introduction of PUBWEAK symbols in XLINK 4.50C.

- EW16567 When producing UBROF output and linking input files where the first bytes of a segment part were not present (this can be achieved by using the ORG directive in the assembler), XLINK could produce corrupt debug information that made the C-Spy debugger abort when the file was read.

- EW16580 When producing UBROF output and doing packed segment placement (-P) where two or more placement commands placed segments in the same address range (example: -P(DATA)BANK_N=[0-7FF]/100 -P(DATA)BANK_0=0-FF -P(DATA)BANK_1=100-1FF) XLINK could produce a UBROF file where the segment placement debug information contained duplicate entries. This could cause C-Spy to abort when the file was read.

- EW16581 When producing UBROF output, XLINK used an incorrect format for three of the subfields in the statement info record type introduced in UBROF 9. As all IAR tools are insensitive to this error, this can only lead to problems if using a UBROF reading tool from another vendor.

- Absolute segments no longer have " (ABS)" added to their name in the linker list file.

- Consecutive absolute segment parts are now merged in the segment map (-xs) in the linker list file.
- The empty load (-E), conditional load (-C) and forced load (-A) options now work slightly differently. A file may now be specified several times, once without any option and once for each option (although -A and -C are mutually exclusive).

  Earlier, the following was an error:

           xlink -A foo.rXX foo.rXX -f lnk.xcl

  This is now allowed, foo.rXX will be treated as an input file and the behavior will be as if -A had been specified.

- The MISRA C checks that were introduced in XLINK 4.59B were not documented at the time, now they are. See xman.htm for the details.

#### XLINK 4.59J - 2005-01-14

- EW16216 When doing static overlay, XLINK could fail to issue warning 16 (function is called from two function trees) even if a warning was called for. This problem was introduced in XLINK 4.56B.

- EW16349 When linking files that using the ASEG assembler directive placed code on addresses above 0x7FFFFFFF, XLINK terminated with an internal error. This problem was introduced in XLINK 4.55A.

- EW16350 When linking files for the 6502 processor, XLINK could terminate with an internal error. This problem was introduced in XLINK 4.55A.

- EW16354 When linking the result of a compilation of a truly empty (0 byte) file, debug information was generated and using UBROF 8 or later, XLINK could terminate with an internal error.
- A new format variant for the xcoff78k format, -yn, has been introduced. The new format variant offers better support for NEC's debugger in some cases. See xman.htm for more details.

- Support for the Motorola hcs12 processor has been added.

#### XLINK 4.59I - 2004-12-15

- EW16157 When producing ELF/DWARF output, XLINK could, under rare circumstances, terminate with an internal error. This problem was introduced in XLINK 4.58H / XLINK 4.59B.

- EW16196 When generating the linker list file and the -d option (disable code generation) was specified, XLINK terminated with an internal error. This problem was introduced in XLINK 4.51G.

#### XLINK 4.59H - 2004-11-24

- When generating output in the COFF format, XLINK now offers better support for the MPLAB debugger.

#### XLINK 4.59G - 2004-11-18

- EW16041 When doing segment duplication (-K), XLINK failed to duplicate segments with absolute addresses (like the interrupt vector in some versions of the ICC78000 compiler).

- EW16101 Starting with XLINK 4.58A, XLINK failed to detect corrupt files and emit error 20 (Corrupt file. External index out of range in module module(file)). This can only happen for corrupt UBROF files where a UBROF file makes a reference to an external label that is not declared in the UBROF file.

- EW16133 When linking object files for the ARM processor and producing a linker list file, XLINK now better handles the case where a segment part has two labels (this primarily happens for the interwork mode in ICCARM). A symbolic name is usually found and XLINK rarely claims that an entry is "referenced by segment part xxxx".

- EW16134 When generating ELF/DWARF, using packed segment placement (-P) where CODE and CONST segments were placed in the same address ranges, XLINK could produce corrupt ELF/DWARF files.

- EW16135 When doing Relay Function Optimization for the ARM processor and using packed segment placement (-P), XLINK could in rare cases terminate with an internal error. This problem has been present in XLINK since the introduction of Relay Function Optimization in XLINK 4.58A.

#### XLINK 4.59F - 2004-10-18

- EW15895 A range error referring to a symbol defined by the -J (calculate checksum) option resulted in an internal error. This problem was introduced with the expanded checksum functionality in XLINK 4.59E.

- EW15896 When producing output in the UBROF 6 or earlier UBROF versions and the input files contained arrays with more than 65535 elements, XLINK could terminate with an internal error. The output file will now instead contain erroneous debug information in this case as the output format can not express debug information for arrays of that size.

- EW15901 When generating output in the COFF output format, XLINK could produce corrupt output if the image contained any common segments. This problem was introduced in XLINK 4.59B / XLINK 4.58H.

- EW15930 When generating output in the XCOFF78K format, XLINK failed to generate debug information for the first assembler module if it also was the first module. This problem was introduced in XLINK 4.59B / XLINK 4.58H.

- EW15979 When generating the error message for error 16 (segment too long), XLINK now specifies the address space of the address only when the processor actually has more than one address space.

#### XLINK 4.59E - 2004-09-15

- EW15555 Two lines have been added to the module summary part of the linker list file, to account for memory use that is not assignable to a specific module.

- EW15626 When generating a linker list file in HTML format, the Module Map and Segments in Address Order tables were not formatted correctly.

- EW15819 For certain products with a compiler using UBROF 9.0 or later, an assembler using old style line number information and when linking assembler files containing debug information, XLINK could produce corrupt output that was not accepted by the C-Spy debugger.

- EW15822 When using the always generate output option (-B) and linking did not stop after error 16 (segment is too long) XLINK could in rare cases terminate with an internal error.

- EW15833 When generating additional output files (using -O) and the format of the additional output file was simple-code, XLINK could terminate with an internal error.

- EW15846 Type matching could sometimes fail for deeply nested circular types, resulting in spurious 'undefined external' (e46) errors. Type matching for the purpose of name resolution has now been changed to eliminate this problem.

- EW15875 When doing packed segment placement (-P), relay function optimization and there were relay functions that had the segment property REORDER (the segment parts of this segment in the module may be reordered by the linker), XLINK could fail to perform relay function optimization and terminate with an internal error. Note: The ICCARM compiler never generates relay functions that are REORDER.

- EW15878 When using the require global entries option (-g) and a required symbol was not present in the input files, XLINK did not emit error 46 (undefined external).

- XLINK can now generate output in the simple-code format. Simple code is a simple binary format that is primarily intended as a format for flash loading. Support for simple-code was introduced in XLINK 4.59C but is made public in the documentation for 4.59E. See xman.htm for the details.

- XLINK can now generate output in the raw-binary format. Raw binary is a binary image format. It contains nothing but pure binary data. See xman.htm for the details.

- XLINK can now read a raw binary image and link its contents.

        --image_input=file,symbol,segment,alignment

  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.

  See xman.htm for further details.

- A new experimental feature has been added. XLINK is now capable of producing an arbitrary number of checksums. See xman.htm for the details.

- A new experimental format variant, 1 (-Y1), has been added to the aomf8051 output format. It can be specified to make XLINK use the SEGID field to contain the bank number (0-0xFF) of addresses greater than 0xFFFF. If this experimental option is not used the SEGID field will always be 0. Note that this is a non standard extension of the aomf8051 format.

#### XLINK 4.59C - 2004-06-30

- EW15575 When doing Relay Function Optimization, XLINK could in rare cases terminate with an internal error. This problem was only partially fixed in XLINK 4.59B.

#### XLINK 4.59B - 2004-06-29

- EW15288 When doing output in the AOMF8051 format and linking files from the icc8051 compiler version 6, XLINK could produce incorrect code if any of the input files had debug information for a block local variable.

- EW15404 When producing output in the XCOFF78K format and input files were generated by version 3 of the ICC78000 compiler, XLINK generated spurious zeroes in the interrupt vector.

- EW15532 When generating output in the XCOFF78k format, XLINK could generate incorrect debug information for the first function in each input file, this lead to strange behavior in the debugger. This problem was introduced in XLINK 4.58F.

- EW15568 When producing multiple UBROF files using the -O command, XLINK could fail to generate filler bytes and macro information for files except the first.

- EW15574 When reading input in UBROF 9 or later and producing output in UBROF 8 or earlier, or one of the output formats: ELF, COFF, XCOFF78K, IEEE695, the debug information concerning the relationship between source statements and source blocks was sometimes incorrect. This could lead to problems loading the file into a debugger or in setting breakpoints on some statements.

- EW15575 When doing Relay Function Optimization, XLINK could in rare cases terminate with an internal error.

- EW15576 When Relay Function Optimization was critical for making the program fit in the specified ranges, XLINK could terminate with an internal error.

- EW15577 When producing ELF/DWARF for the M32C processor, XLINK could produce corrupt debug information for auto variables.

- Support for the COFF format used by MP-Lab 6.50 for the DSPIC processor has been added.

- When generating the information about which ranges that are occupied for error 104 (failed to fit all segments into specified ranges) and error 16 (segment is too long for segment definition), consecutive ranges are now merged resulting in more compact and readable error messages.

#### XLINK 4.59A - 2004-06-10

- EW10553 [XLINK0145] When producing ELF output for the ARM processor and the input files did not contain debug information, XLINK failed to produce a file that was accepted by the ARM debugger.

- EW15502 When linking files containing references to undefined externals, XLINK could produce a corrupt error message text. This problem was introduced together with the relaxed link model in XLINK 4.58B.

- EW15503 When using the -V option (create relocation area) with an output format that did not support relocatable output and always generate output (-B) was specified, XLINK terminated with an internal error.

- EW15504 When linking files containing static functions/variables or block local structs/unions and producing output in one of the formats NEC, tektronics, hp-symb, mpds, sysrof or IEEE695, XLINK erroneously generated error 119 (Cannot handle C++ identifiers in this output format).

- EW15505 When generating output in the IEEE695 format and at least one module contained segment parts that were not included in the output, XLINK could produce corrupt output.

- EW15506 When generating relocatable ELF/DWARF for the ARM processor, XLINK could generate output where code areas had data attributes and data areas had code attributes. This problem was introduced in XLINK 4.58A.

- EW15507 When generating ELF/DWARF, XLINK did not generate debug information for static functions. This problem was introduced in XLINK 4.56C.

- EW15508 When producing UBROF versions lower than 9 and the input files were UBROF 9 or higher, XLINK could terminate with an internal error. This problem was introduced in XLINK 4.58E.

- EW15509 When doing Relay Function Optimization and there was not enough space for the segments, XLINK could terminate with an internal error.

- EW15511 When doing Relay Function Optimization, using filler bytes (-H) and placing the segments using packed segment placement (-P), XLINK could generate filler bytes that overlapped the code bytes. This problem has been present in XLINK since the introduction of Relay Function Optimization in XLINK 4.58A.

- XLINK now requires significantly less time and memory.

- Error 106 (Syntax error or bad argument) is now a fatal error (fatal errors can not be suppressed).

#### XLINK 4.58G - 2004-05-13

- EW15395 When linking files containing multiple references to an undefined external, XLINK failed to give error 46 (undefined external) if the first reference was made by a suppressed segment part. This problem was introduced in XLINK 4.58B with the more relaxed link model.

- EW15411 When checking for segment overlap between absolute and relocatable segments, XLINK would terminate with an internal error if an overlap was found. This problem was introduced in XLINK 4.58A.

- EW15423 When using the -s option (specify entry point), XLINK used the address of the label's segment part, not the address of the label, as the program's entry point. This did not work if the label was not placed at the start of a segment part. This problem has been present since the introduction of -s in XLINK 4.58A.

- EW15424 When doing Relay Function Optimization, XLINK now behaves better when the program does not fit in the available ranges before Relay Function Optimization.

- EW15425 When doing Relay Function Optimization, XLINK could in rare cases fail to disregard suppressed relay functions. The suppressed relay functions were not output, but they could affect the placement of other segment parts and could result in incorrect code. This problem has been present since the introduction of Relay Function Optimization in XLINK 4.58A.

#### XLINK 4.58F - 2004-04-14

- EW15234, EW15284When doing sequential segment placement (-Z), XLINK did not correctly mark the entire consumed address ranges as reserved, which could in rare cases lead to later segment placement commands erroneously placing segments or segment parts into what looked like gaps left by the sequential segment placement command. This could result in segment overlap errors while linking or memory overwrites during program startup.

- EW15237 When generating the linker list file, the size of bit ranges was reported as being in bytes even though the actual number was the size of the range in bits.

- EW15278 When producing relocatable ELF/DWARF output and performing Relay Function Optimization, XLINK could produce corrupt output.

- EW15279 When producing relocatable ELF/DWARF output and generating a linker list file, XLINK did not print the relocation areas of segments. This problem was introduced in XLINK 4.58A.

- EW15280 When generating the error text for error 24 (segment overlap), XLINK could report the overlap as being for another segment than the actual overlapping segment. This problem was introduced in XLINK 4.58A.

- When performing Relay Function Optimization and doing packed segment placement (-P), XLINK now produces fewer special packed segments than previously. This has no effect on the generated code but results in list files that are easier to read.

#### XLINK 4.58E - 2004-03-24

- EW14976When overriding error 16 (Segment segment is too long for segment definition.) and the first available address of the range of the segment that didn't fit was unaligned, XLINK could terminate with an internal error.

- EW14988 XLINK is now able to produce output in the xcoff78k format when the input files are generated by the new icc78k compiler.

- EW14998 The 4.58 series of XLINK did not handle UBROF version 9.1.2. This version is only used by the M16C processor.

- EW15068 When producing ELF/DWARF output, XLINK generated incorrect line number information for line numbers greater than 65535.

- EW15069 When performing Relay Function Optimization and a symbol with a fixed address (this includes absolute symbols and symbols defined using -D) was referenced by a relay function, XLINK terminated with an internal error.

- EW15070 When producing ELF/DWARF output, XLINK terminated with an internal error if the command line option -q (disable Relay Function Optimization) was used in a case where Relay Function Optimization would have had an effect.

- EW15091 When producing ELF output, XLINK set the wrong alignment in the program headers. This did not matter much because the program header already had an assigned address. This problem has always been present in XLINK.

- EW15092 When producing symbolic error messages involving absolute symbols, XLINK could terminate with an internal error.

- EW15093 When performing Relay Function Optimization and using packed segment placement (-P), XLINK could in some cases terminate with an internal error.

- The banked segment placement command (-b) does not handle the requirements on adjacent placement that modern compilers sometimes place on segment parts. XLINK now emits error 145 when such segment parts are placed using -b. Segment placement using the packed segment placement command (-P) does handle these requirements.

#### XLINK 4.58C - 2004-03-05

- EW14965 When an undefined external was involved in a range error, XLINK could terminate with an internal error.

- EW14967 When an absolute placed segment was involved in a range error, XLINK could terminate with an internal error.

- EW14989 When checking for the presence of the correct version of the C runtime library XLINK could emit both error 88 (Library tag tag not found.) and error 46 (Undefined external), instead of only error 88. This behavior was introduced in XLINK 4.58B.

- EW14990 When generating the module summary (-xn) in the linker listfile, XLINK could in rare cases terminate with an internal error.

- EW14991 When mixing C and C++ files where a typedef is used to name an anonymous enumeration type, like this:

      typedef enum { a, b } c;

  In this case XLINK would needlessly generate a type conflict warning for any variables or functions whose signature involved the type.

- EW14994 When undefined externals were involved in Relay Function Optimization, XLINK could terminate with an internal error.

- EW14995 The reported address for certain symbols in range errors (error 18/warning 47) was incorrect. The address reported for module local relocatable symbols was based on the start of the segment to which they belonged, rather than the start of the segment part to which they belonged.

#### XLINK 4.58B - 2004-03-01

- EW14964 When performing relay optimization, XLINK could remove a relay function that was actually needed under some circumstances. This resulted in incorrect code.

- Beginning with version 4.58B, XLINK employs a more relaxed link model. Undefined external errors (error 46) are now generated only if the referenced symbol is actually needed by the program. Previously, the error was generated if any included module referenced the symbol, even if the parts of the module that referenced the symbol were later discovered not to be needed in the final program.

#### XLINK 4.58A - 2004-02-17

- XLINK now performs Relay Function Optimization for the ICCARM compiler version 4.10 and later. As part of this change the internal version of UBROF used between the compiler and the linker was raised to 10.0.1. A new error (error 144) can be generated during Relay Function Optimization if the preconditions for this optimization are violated. A new command line option, -q, can be used to disable Relay Function Optimization.

- A new command line option, -s, can be used to specify the entry point of an image.

- XLINK/XLIB/XAR now support the processors DSPIC, MAXQ and x51 (ICC8051 version 6).

#### XLINK 4.56H - 2004-02-11

- EW14692 When linking files that contain SFB and SFE (the start and end address of a segment) references to a packed segment but where those references were not needed (and thus not included) in the output, XLINK could terminate with a "segment didn't fit" internal error.

- EW14754 When producing COFF output for input files that contain block-local struct or union types, XLINK erroneously classified these as C++ identifiers. This resulted in error 119 ("Cannot handle C++ identifiers in this output format").

- EW14806 When using the output format COFF, XLINK did not check that the number of line number data entry records did not exceed the maximum (64K) in the section header for each section, resulting in drastic loss of debugging usability. XLINK now issues a warning in this case (warning 59) and includes as many entries as can fit. For the MPLAB debugger for the PIC processor, one line number data entry record is needed for each instruction.

- EW14819 When linking a file that contains two or more PUBWEAK entries for a single segment part, XLINK could silently fail to determine the address of the segment part and would use address 0 instead of the correct address. XLINK now checks explicitly for this error condition and emits error 143.

  The ARM compiler could generate such erroneous code for inline functions in interwork mode. It is also possible to write assembly code for any processor that triggers the problem.

- EW14848 When producing output in the ELF/DWARF format, XLINK did not correctly align the sections in the ELF/DWARF file on a 4-byte boundary, except when producing output for the ARM Ltd ARM debugger. Note: This only concerns the representation of the program in the ELF-file, not the program itself.

- When producing output in the UBROF version 7 or older XLINK did not handle symbol and type names longer than 255 characters correctly. Such symbol and type names result primarily from the flattening of C++ names that is performed when translating C++ modules using UBROF 8 or later to an earlier version of UBROF. Any such names would result in a corrupt output file from XLINK. When needed, the name is now truncated and warning 58 is issued.

#### XLINK 4.56F - 2003-11-24

- EW14666Turning off global type checking (-G) in the linker had no effect on the time needed to link. In cases when type checking consumes significant amounts of time, XLINK now links less slowly if global type checking is turned off.

- EW14672 When producing output in the formats UBROF 5 - UBROF 9 and the total number of types in the program exceeded 64k, XLINK produced corrupt output files. This will now result in an error. UBROF 10 has no limit on the number of types in a program.

- EW14673 When generating the error text for range errors, XLINK could sometimes terminate with an internal error when looking up the name of a segment.

- When linking files that contain large circular types, XLINK now spends significantly less time checking the types.

#### XLINK 4.56E - 2003-11-10

- EW14544 When linking files that contained modules that were small enough to fit in a single block of the internal buffer and contained debug information, XLINK could terminate with an internal error.

- EW14577 When producing multiple output files (-O), the second file could contain only zeros if the first output file was in UBROF format or one of the simple debug formats ( pentica (all), symbolic, aomf80196, sysrof, nec2-symbolic, nec78k, zax, nec-symbolic, aomf8051, hp-symb, mpds-symb, ashling, symbolic, typed). This problem was introduced in 4.56A.

- EW14594 When producing symbolic range check error messages (introduced in XLINK 4.55D), XLINK did not handle some of the older (UBROF 6 and below) link range tests correctly, causing it to terminate with an internal error.

- EW14611 When linking files containing PUBWEAK symbols and one PUBLIC symbol in an ASEG (absolute assembler segment), XLINK would terminate with an internal error. Definitions in ASEGs are not allowed in the PUBLIC/PUBWEAK resolution. Note that definitions in ASEGN:s (assembler segment which has a segment part with an absolute address) are allowed.

- EW14612 When linking files containing assembler symbols, XLINK could include those symbols in the output even if they were suppressed.

- The error message for error 105 ("Recursion not allowed for this system. Check module map for recursive functions") has been updated. The new error message is: "Recursion not allowed for this system. One recursive function is function"

- The address limit for the output format `mpds-code` has been removed, it was previously set to 16MB.

- It is now possible to combine the options -r{char} (generate debug information for IAR's C-Spy debugger) and -O (generate multiple output files). -r picks special modules in the runtime library to allow better debugging in C-Spy. When -r is used with -O, all generated files will contain the special C-Spy modules, they will not work well when run in an environment not involving C-Spy. Under special circumstances the combination of -r and -O is exactly what you need but they should not be routinely used to generate additional output files in the belief that the additional output files can be used just like a file in the same format that is generated using -F.

  Example:
  `xlink -rt -Omotorola=.mot -o output.dXX ...
  `

  This will generate two output files, one UBROF-file (output.dXX) with terminal I/O debugging support and one motorola file (output.mot) which has the same byte content as output.dXX.

  `xlink -rt -o output2.dXX ...
  xlink -Fmotorola -o output2.mot ...
  `

  This sequence of link commands will also produce two output files, one UBROF-file (output2.dXX) that is the same as output.dXX and one motorola file (output2.mot) that is NOT the equivalent of output.mot as the special C-Spy modules in runtime libarary are not chosen.

#### XLINK 4.56D - 2003-10-08

- EW14486 When doing SPLIT- or FAR downward segment placement (-Z(Type)Segments#Range), XLINK placed the segment parts in reversed order. In the SPLIT- case this lead to that the entire segment was listed as residing at an incorrect address and having an incorrect size (if the segment had more than 1 segment part).

- EW14488 When linking a project that ignores cstartup, without supplying a replacement (this lead to an empty prgram), XLINK did not report any byte useage. This caused a "Build aborted" error when XLINK was run from the Embedded Workbench.

- EW14505 When doing list-object-code, XLIB could not display the UBROF tag t_push_prm_arg_bl1.

- EW14516 When producing the IEEE-695 and COFF formats, a buffer overrun problem could cause XLINK to produce incorrect debug information. This problem was introduced in XLINK 4.55B.

#### XLINK 4.56B - 2003-09-23

- EW14053 When run without arguments from the command line, XLINK now outputs all options and exits without waiting for input.

- EW14207 When generating ELF/DWARF output for the ARM processor, XLINK mistakenly considered files that contained VFP-doubles to be corrupt.

- EW14341 When producing COFF output for files that contained static functions or variables, XLINK terminated with error 119 ( "Cannot handle C++ identifiers in this output format" ) even if the files weren't C++ files.

- EW14406 XLINK terminated with an internal error when the -n option (suppress all module local symbols) was used with the ELF output format.

- EW14428 XLINK no longer exits with a fatal error when only the -v (print version information) command line option is used.

- EW14430 When producing ELF/DWARF, XLINK could generate incorrect debug line information if the distance from one statement to the next was larger than 0x20000000.

- EW14434 While producing a module summary (-xn), XLINK could terminate with an internal error. This problem has been present in XLINK since the introduction of -xn.

- EW14435 While producing error messages for range errors, XLINK could termiante with an internal error if the code responsible for the range error was located in the last file block of the input file. This problem has been present in XLINK since the introduction of the new range errors messages.

- EW14446 When generating filler bytes for common segments, XLINK did not generate any filler byte for the bytes in the common segment that had no defined value.

- When doing function auto storage layout for processors that use the static overlay system, XLINK now only emits warning 16 (function is called from two function trees) when the called function actually needs any static overlay storage space.

- A new segment placement command modifier, SPLIT-, has been introduced. The SPLIT- modifier is only available for -Z (sequential segment placement) and allows XLINK to place the individual segment parts of the segment non-contiguously.

  See xman.htm for more information on the new feature.

- The -U command line option (address space sharing, introduced in XLINK 4.53A) is no longer considered to be experimental.

  `-U[(segment type)]ranges1=[(segment type)]ranges2`

  All segments placed into any range in ranges1 is also placed in the corresponding range in ranges2.

  See xman.htm for more details of -U.

- The memory requirement of XLINK have been significantly reduced in many cases.

- When producing two or more output files where at least one is a simple output format without debug information (for instance Intel Hex or Motorola S-records ) XLINK now requires significantly less time.

#### XLINK 4.55J - 2003-06-26

- EW14141 When linking files that contained debug information and at least one segment had more than 65535 segment parts, XLINK would terminate with an internal error. This could only happen for the COFF, ELF/DWARF, IEEE och XCOFF output formats. This problem has always been present in XLINK.

- EW14142 When generating ELF/DWARF output for the ARM processor, XLINK considered files that contained VFP-registers to be corrupt.

- EW14143 When generating UBROF-files, if the next address would have been 0x100000000 (for example when a long is placed on address 0xFFFFFFFC) XLINK terminated with an internal error. This problem was introduced in XLINK 4.55B.

- The memory requirement of XLINK have been somewhat reduced.

- Linking files that contains many (tens of thousands) segment parts in the same segment now requires significantly less time.

#### XLINK 4.55I - 2003-06-06

- EW14022 When outputting UBROF version 10 files involving C++ code, XLINK generated incorrect skip information for some T_SCOPED_NAME records. The effects of this is limited to certain rare UBROF readers not used for debugging.

- EW14041 When producing COFF output, XLINK did not handle neither bool nor wchar_t, and terminated with an internal error if either was encountered.

- EW14080 When producing output in the xcoff format and the debug information for an auto variable contained a negative offset from a stack or frame pointer, XLINK terminated with an internal error. This problem was introduced in XLINK 4.55B.

- EW14081 When linking files containing an ORG in absolute code with an address higher than 0x7FFFFFFF, XLINK would terminate with an Internal Error. This problem was introduced in XLINK 4.55B.

#### XLINK 4.55H - 2003-05-13

- EW13945 When linking files for any target with static overlay, XLINK generated an internal error if absolute code made a reference to an external function. This problem was introduced in XLINK 4.51K.

- EW13954 Xlink did not terminate when a '\' was used outside of a quoted ("") sequence in the environment variable XLINK_ENVPAR. This problem was introduced in XLINK 4.53N.

- EW13956 When generating ELF/DWARF for the M16C processor, XLINK did not generate debug information for the register pairs R0H:R0L and R1H:R1L. This problem has been present since the introduction of ELF-support for M16C in XLINK 4.55D.

- EW13987 When SFB or SFE was used on a segment containing tentative segment parts (PUBWEAK symbols) and the included definition was located in a different segment, XLINK generated the wrong value for the SFB/SFE.

- EW14006 See Important Information for 4.55H for more information.

- EW14007 Packed segment placement (-P) did not work as intended. The resulting placement could utilize memory less efficiently than what would normally be the case. The problem was introduced in XLINK 4.55B.

- When using packed segment placement (-P), the order of the segment names in the list of segments that were combined was not correctly sorted in alphabetical order. This does not affect the addresses of segments in any way, it is a pure cosmetic change in the map-file.

- When producing xcoff78k, XLINK no longer adds a _ to assembler symbol names.

#### XLINK 4.55G - 2003-04-11

- EW13795 When producing DWARF debug information, XLINK generated the wrong offsets for bitfields of enum type.

- EW13806 When producing ELF/DWARF, it is now possible to strip the source file paths from the debug information using the fomrat variant option -yx.

- EW13827 XLINK generated an internal error when the environment variable XLINK_ENVPAR was set. This problem was introduced in XLINK 4.55B.

- EW13830 When doing address translation (-Mrange1=range2) XLINK would never terminate if neither of the involved ranges started at address 0. This problem was introduced in XLINK 4.55B.

- EW13877 The experimental -P$ option did not always honor the keep-with-next properties (that the segment parts needs to be placed sequentially) that some segment parts have.

- The linking process will require less memory when producing ELF/DWARF-files. This has no impact on the generated image.

- When producing ELF/DWARF for the ARM processor, XLINK now aligns the sections on 4-byte boundaries in the file.

- XLINK no longer generates an error when it encounters a totally empty (0 bytes) file. The empty file is ignored and warning 57 is generated.

#### XLINK 4.55F - 2003-03-13

- EW13602 When linking files for the SAM8 processor, XDATA is now considered to be an address space that does not overlap the DATA address space.

- EW13673 When linking files than contained references to undefined externals, XLINK generated an internal error. This problem was introduced in XLINK 4.55B.

- EW13680 When a segment did not fit in the available ranges and at least one bit segment had been placed, the ranges that XLINK presented as relevant to the occupied memory could be both superflous and erroneous.

- EW13681 When placing bit segments, XLINK reserved 1 byte too much space. If the segment consisted of 15 bits it would occupy 3 bytes instead of the expected 2. This problem was introduced in XLINK 4.55B.

- EW13698 When the entry point of the program was located in a function that was suppressed (not included in the output) XLINK would crash. Note: It does not make sense to have the program's entry point in a suppressed function.

- EW13705 XLIB did not always handle UBROF 10 files correctly. Some operations produced corrupt output when the number of types (including the built in ones) was below 128 or above 32767. The list commands (with the exception of list-object-code) and all commands that produced a new file did not handle UBROF macros.

- A new list file option, -xn, generate module summary, is now available. It was actually introduced in XLINK 4.55B but it was not documented in neither this file nor in the command line help. See xman.htm for details of -xn.

#### XLINK 4.55D - 2003-02-13

- EW12541 When generating listfiles XLINK no longer always claims that the first label in a segment part makes all references in that segment part. If a segment part contains several labels XLINK now lists its number instead of claiming, possibly erroneously, that a certain label is the referer. This mainly affects older tools (UBROF 6 and older) but might affect newer tools too if they contain segment parts with many labels (e.g. assembler modules).

- EW13250 When doing banked segment placement (-b), XLINK could erroneously give error 107 (Banked segments do not fit into the number of banks specified) if the optional count (maximum number of allowed banks) parameter was used and several segments could reside in the same bank.

- EW13273 When trying to produce C++ IEEE695 output for the M32C processor XLINK crashed instead of giving an error message. Note: IEEE695 for C++ programs is currently not supported.

- EW13370 Absolute code placed on addresses above 0x7FFFFFFF caused XLINK to crash. This bug was introduced in 4.55B.

- EW13377 When producing output in the COFF format, xlink erroneously claimed that locally defined unions were C++ identifiers.

- EW13412 XLINK crashed when -H (fill unused code memory) was used without a hexstring. This now results in error 39 (illegal character specified in option).

- EW13449 When using the static overlay system XLINK now checks that a function uses at least 1 byte of static overlay before emitting warning 39, (The function function in module module (file) does not appear to be called. No static overlay area will be allocated for its parameters and locals.)

- EW13455 When producing ELF/DWARF output for the M16C processor XLINK emitted the wrong frame pointer offset for auto variables and were unable to represent the location of some register pairs.

- EW13566 When the force output flag (-B) was used and some address ranges could not be placed, XLINK would crash with an internal error. This bug was introduced in 4.55B.

- EW13568 When producing listfiles, XLINK did not handle special characters, å,ä,ö,ü..., correctly.

- EW13578 When producing UBROF 10, XLINK emitted the wrong size for t_symbol_def:s if the total number of types in the progam (including the built in ones) was above 16383 or below 128.

- Starting with version 4.55D XLINK presents range errors (error 18) in a new way, see xman for the details.

#### XLINK 4.55C - 2003-01-20

- EW13286 XLINK has been updated to report absolute code and data separately in the memory summary, as these are usually of less interest.

- EW13328 When run from IAR Embedded Workbench with the Force Output option set, XLINK returned the wrong return code if errors were encountered. This resulted in the Workbench removing the generated file.

- EW13346 XLINK could erroneously report a type conflict for cases where some type attributes (like const or volatile) were part of a typedef type.

- EW13358 Xlink crashed when trying to generate ELF for all targets other than ARM. This bug was introduced in 4.55B.

- EW13391 Error 27, "entry entry in module module redefined in module module" is now non fatal. This means that it is possible to list all multiply defined entries in a program in a single pass if the force output flag (-B) is set.

#### XLINK 4.55B - Beta Release - 2002-12-17

- XLINK can now produce relocatable output. Details on that and the changes below can be found in xman.

- A new command line option, -g, makes it possible to tell xlink to include entries that are not referenced from the program.

- A new command line option, -V, can be used to create relocation areas.

- Using the new -xi option it is now possible to list all segment parts in a list file, not just the ones that were included in the output.

- A new way of specifying ranges ([start:+size]) is now available.

#### XLINK 4.53P - 2002-11-15

- EW12961 XLINK did not create intra segment fillers as it should when the range specific version of filling (-h) was used.

- EW12964 Filler bytes no longer count towards the maximum number of bytes in product packages that are limited.

- EW13002 XLINK now allows the prefix 0x on hexadecimal numbers in defines and placement commands (e.g. -DROMSTART=0x8000 and -Z(CODE)MYCODE= 0x1000-0xFFFF are now legal) both on the command line and in .xcl-files.

- EW13003 XLINK could fail to emit a t_org before the first byte of an absolute assembly language file. This could result in broken images as those bytes would count as a part of the last emitted t_org.

- EW13167 XLINK could produce illegal UBROF when converting statement information from a UBROF 9 file to a UBROF 8 file.

#### XLINK 4.53O - 2002-10-17

- EW12695 When using scatter loading, the -Q option, XLINK gave different sizes for the initialized segment and the initializer segment when the initialized segment was suppressed (not included in the output). This problem has been present since the introduction of -Q in 4.51K, released 1999-08-24.

- EW12711 XLINK placed absolutely placed DATA and XDATA objects in the same address space in the UBROF output format. If the objects collide C-Spy detects this. This problem was introduced in 4.53F, released 2001-11-30.

#### XLINK 4.53N - 2002-09-16

- EW12413 XLINK crashed when producing output in the aomfx96 format for the x96 processor and the --module_name= option for the x96-compiler were used with an empty string.

- EW12484 XLINK now handles "\ " (backslash space) in .xcl-files correctly. These were treated as a single character earlier.

- EW12643 When generating ELF/DWARF output XLINK used an incorrect offset for statement information using the const_add_pc tag. This lead to discrepancies between the generated file and the compiler list file and could result in the debugger setting a breakpoint at the wrong location.

- When producing ELF/DWARF output XLINK now uses the end point of the source line information to set the column and row number. Older versions of XLINK used the start point of the source line information to set the column and row number. Setting the numbers to the end of the source line information instead of the start should lead to improved compatibility with some third party debuggers while remaining compatible with others.

#### XLINK 4.53M - 2002-07-10

- EW12099 The experimental -P$ placement command is introduced in 4.53M. It allows XLINK to break up segments that would normally be placed as a contiguous chunk.

- EW12165 When doing static overlay XLINK warned unnecessarily about a function being called from two roots (warning 16) when one of the callers was suppressed (not included in the output).

- EW12187 Due to a change in the way static functions and variables are emitted in IAR compilers outputting UBROF version 9 or later XLINK would generate error 119 (Cannot handle C++ identifiers in this output format) when any of the linker output formats (* has the usual "match all" meaning here): aomf*, ashling*, mpds*, msd*, nec*, pentica*, symbolic, sysrof, typed, zax* were selected and at least one of the input files was compiled using such a compiler.

- EW12267 It is now possible to turn off error 2 (Too many errors encountered) using -we2=i. This will result in no limit on the number of errors XLINK will emit.

- EW12268 When producing output in the ELF/DWARF format for the ARM processor XLINK did not handle variables being placed in the link or stack pointer registers, erroneously claiming that the input file was corrupted.

- EW12277 XAR now warns when the same filename is specified more than once.

- EW12278 XAR now allows the user to specify object files in a separate file. This makes it possible to avoid the problem that the command line can become too long for certain operating environments. Details about this can be found in the xar.htm file.

#### XLINK 4.53L - 2002-05-30

- EW11847 XLINK failed to allocate extra space (the +NNNN in the segment definition command) for segments that were created on the command line and placed using far placement. This bug was still present in 4.53K.

- EW12002 When using the static overlay system XLINK warned, [w39], for uncalled functions that weren't included in the output file.

- EW12019 XLINK could produce erroneous debug information when two libraries contained the same symbol, one of the definitions was strong and the other weak and the weak definition was encountered before the strong one.

- EW12063 XLINK could crash when trying to link modules with more then 32767 types. XLIB could crash when trying to list object code on output files with more than 32767 types.

#### XLINK 4.53K - 2002-04-17

- EW11802 XLINK crashed while trying to handle empty loaded common segments.

- EW11806 Type checking could result in an internal error for deeply nested circular types.

- EW11815 XLINK removed unused segments without taking into account that other segments might depend on the unused segment being present at some address.

- EW11821 XLINK erroneously claimed that some names of structs and unions were C++ identifiers for the IEEE-695 format for UBROF 8 and later.

- EW11836 XLINK erroneously claimed that the names of some variables were C++ indentifiers for the coff format for UBROF 8 and later.

- EW11847 Xlink failed to allocate extra space (the +NNNN in the segment definition command) for segments that were created on the command line and placed using far placement.

#### XLINK 4.53J - 2002-03-18

- EW11621 Type checking for K&R functions has been weakened to eliminate unwanted type conflict diagnostics for code compiled with newer compilers that provide less detailed information about calls to such functions.

- EW11616 The information about whether a function type involved in a type conflict diagnostic was K&R or prototyped was reversed. K&R function types were marked as prototyped, and prototyped function types were marked as K&R.

- EW11615 ARM-ELF specifies a flag, EF_ARM_HAS_ENTRY, for keeping track of if an image has an entry point or not. XLINK now sets this flag for the ARM processor when outputting ARM-ELF/DWARF.

- EW11572 XLINK erroneously treated a register pair as two registers for the M32C processor in the ELF/DWARF output format.

- XLINK/XLIB now support the U8 target.

#### XLINK 4.53I - 2002-02-19

- EW11520 XLINK calculated the wrong value for SFE (Segment End) directives for segments placed using far placement when the entire segment did not fit in a single 64K page. See Important information for 4.53I.

- EW11515 XLINK now removes worthless segment placement commands so that it is possible to place them into unavailable memory.

#### XLINK 4.53H - 2002-02-15

- EW11430 There was a problem in matching null names read in from object files using UBROF 7 or earlier with those read in from object files using UBROF 8 or later. This could cause spurious type conflict warnings for struct/unions with unnamed fields when one file was compiled as C code and the other as EC++ code.

- EW11362 Linking files using UBROF version 5, compiled with the option -rn (debug info, no source) and containing no functions caused an internal error in XLINK when doing output in UBROF version 5.

- EW11342: XLINK always warned for indirectly called functions doing indirect calls when using static overlay, now the warning is only emitted if any of those functions uses static overlay.

- EW11236 In the module map, each segment part is supposed to get two lines describing the general properties of the segment part. For some segment parts the second line was missing.

- EW11144 XLINK was unable to handle local static variables and static functions for the IEEE-695 format in UBROF 8 and later. It erroneously claimed that those were C++ identifiers.

- EW11014: Coff output from XLINK for the PIC18 processor was rejected by the coff to cod converter.

- Improved conversion from UBROF version 9 to older versions.

- Improved handling of version resource.

#### XLINK 4.53G - 2002-01-15

- EW10952 The default extension for m32c in XLIB was ",r48" instead of ".r48".

- EW10929 The right shift operator used in UBROF relocation expressions now has defined behavior for shift counts of 32 or more.

- EW10922 When absolute segments were placed in non sorted order in the infiles XLINK lost track of them in the listfiles and in the MSP430_txt format.

- Improved handling of DWARF register pairs.

#### XLINK 4.53F - 2001-11-30

- EW10782 Improved handling of scatter loading of common segments.

- EW10713 XLINK crashed when linking completely empty source files with debug information.

- EW10673 XLINK crashed when outputing HTML listfiles on stdout, outputing HTML to file works fine.

- EW10666 XLIB crashed when the file argument to -p is missing.

- EW10665 XLINK crashed when the first module read claims to be of a higher UBROF revision than XLINK can handle.

- EW10664 Using / together with directory names containing . when relying on the default extension caused XLINK to not use the extension and not find the file.

- EW10552: [XLINK0148] When doing output in the MSP430_TXT output format, XLINK included spurious null bytes in common segments (usually interrupt vectors).

- Improved debug info for SFR:s for the H8 processor.

- XLINK/XLIB now support the EZ80 processor.

#### XLINK 4.53E - 2001-10-22

- XLINK208 XLINK could emit superfluous address records during some circumstances when generating intel-extended format.

- XLINK0207 [EW10493] XLINK calculated the wrong size for t_symdol_def1s inside t_grp records. This resulted in t_grp records that were larger than they claimed to be. This was triggered only for UBROF 7 files. UBROF 6 uses t_symbol_def and UBROF 8+ uses t_symbol_def2.

- XLIB0003 [EW10270] XLIB would try to write to write-protected memory when setting a default extension. This caused an access violation in some, but not all, cases.

- Added m32c as a synonyme for mc80.

- Added ELF/DWARF support for mc80/m32c.

#### XLINK 4.53D - 2001-09-21

- XLINK0205: Generating ELF/DWARF, aomf8096, aomf80196 and mpds with debug information for absolute segments containing local symbols would cause XLINK to crash.

- XLINK0204: When using the AOMF251 output format, assembler modules with source line information could cause XLINK to crash.

- XLINK0203: There was a bug in the experimental address space sharing feature (-U) that could cause XLINK to crash.

- XLINK0202: XLINK could crash when reading output from the OMCONV converter used for the 80x96 product.

- XLINK0153: Object data excluded through the use of empty load (-E) still appears as zeros in many binary object formats. This bug was fixed in 4.51S but reintroduced in 4.52A.

#### XLINK 4.53C - 2001-08-09

- XLINK0201: Modules with more than one unnamed struct/union with the same initial field names could cause XLINK to crash during type unification.

- XLINK0200: XLINK crashed when linking files compiled with the H8S compiler.

- XLINK0199: When linking UBROF 5 files and producing UBROF 5 output XLINK erroneously emitted warning 51 (some source reference debug info was lost) and dropped all source reference debug info from the output. This problem was introduced in XLINK 4.52J.

- XLINK0198: XLINK crashed when reading assembler modules with absolute code and no source debug info. This problem was Introduced in XLINK 4.52C.

- XLINK0197: When using the SYSROF output format, assembler modules with source line information for absolute code caused XLINK to crash.

- XLINK0196: XLINK terminated with error e113 (Corrupt input file) when linking modules with root static overlay segment parts when packed segment placement (-P) was used for the segment.

- XLINK0195: Using -e (symbol replacement) with UBROF 9 input caused XLINK to produce corrupt output files.

- Using the `-Fubrof` output format caused XLINK to output a file using the latest UBROF version known to XLINK, and not, as documented, the latest UBROF version used in any of the input files (like `-Fdebug`). This problem has existed ever since the introduction of `-Fubrof` in XLINK 4.49A.

- Eliminated a cause of spurious errors (e115 - incompatible symbol definitions) for symbols included only for debug purposes.

- Corrected a problem where XLINK sometimes excluded statement info for inlined functions.

#### XLINK 4.53B - 2001-06-18

- XLINK0194: XLINK crashed if a located variable and a command line defined symbol had the same name.

- XLINK0193: The fix for source statements after all function code in XLINK 4.53A could cause C-Spy to crash when reading C/EC++ object files compiled with high size optimization.

- XLINK0192: ASEGs in assembler modules could cause XLINK 4.53A to crash.

- Further adjustments the output when using the ELF output format to work better with the CCS debugger from Texas Instruments for the ARM processor.

#### XLINK 4.53A - 2001-06-07

- XLINK now supports an arbitrary number of output files in different output formats. An added feature over the experimental support that has been present since XLINK 4.51G is the possibility to restrict the output in one file to only one address space. See xman.htm for more information.

- Added support for the cr16c processor.

- For the u8 processor, the CONST segment type is now considered to be in the same address space as the CODE segment type.

- Using the -ym format variant modifier (Output types in each compilation unit, instead of once for all) for the output format ELF resulted in XLINK producing an illegal output file.

- Improved the prospects for continuing meaningfully (via -B) after a Segment Already Defined error (error 101).

- XLINK0191: XLINK sometimes ignored the alignment specification for empty segment parts. This could cause incorrect code to be generated. This problem was introduced in XLINK 4.49A.

- XLINK0190: XLINK crashed if a range error was detected in absolute code (assembler ASEG). This problem was introduced in XLINK 4.52A.

- When using the output format XCOFF78K, the line number information for block/function end was off by one.

- Some IAR compilers could emit debug information indicating a statement after the end of the code for a function. These are now no longer passed on by XLINK. This is known to have caused problems when using the output format XCOFF78K.

- Adjusted the output when using the ELF output format to work better with the CCS debugger from Texas Instruments for the ARM processor.

- XLINK 4.53A is the first version of XLINK that works with the Embedded Workbench version 3.

- XLINK now outputs more information for error e16 (segment is too long for segment definition). All segments and absolute code that overlap the requested address ranges will be reported. This information will only appear in the linker list file if a list file is being generated. Otherwise it will appear together with the error message on standard output.

- New experimental feature: Address space sharing.

      -U[(segment type)]ranges=[(segment type)]ranges

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

Copyright 2005 IAR Systems. All rights reserved.