Readme file for the IAR XLINK Linker V6.5.0.91
Updated: Apr 11, 2017 [IJYB]
Important information
XLINK 6.2.0.62 - 2015-Feb-11
Starting with XLINK 6.2.0.62 Stack Usage Analysis is supported.
XLINK 6.0.0.46 - 2014-Feb-28
- The IAR Universal Binary Relocatable Object Format, UBROF, has
been updated to version 11.0.0. XLINK will now output UBROF 11
files when given input that contains features that requires
UBROF 11 (currently this is only NOALLOC content).
The UBROF format is used by IAR's C-SPY debugger and a number
of other debuggers/emulators. The new version supports NOALLOC
content. NOALLOC content is program content that resides on the
host instead of on the target processor. This is intended to be
used for debug purposes (typically strings for debug output).
Note that NOALLOC content is only available when running under
a debugger (or something similar), the target processor is
unable to access such content on its own.
XLIB supports UBROF 11 starting with version 6.0.0.46.
All released versions of XAR support UBROF 11.
- The COFF output format is no longer supported.
- The ELF output format for the ARM processor is no longer supported.
- The following processors are no longer supported:
- 740
- 6502
- 8051 (Up to and including icc8051 version 5.X. Version 6.X and above (called x51) is still supported.)
- 65k/65000
- RX (up to and including iccrx version 1.X)
XLINK 5.1.0.8 - 2011-Feb-23
- Starting with XLINK 5.1.0.8 the follwoing features no longer supported:
- Relay Function Optimization (a feature used only in ICCARM
versions 3.41 - 4.42)
- Banked segment placement (-b)
XLINK 5.0.2.5 - 2010-Nov-05
XLINK 5.0.0.1 - 2010-May-17
- Starting with XLINK 5.0.0.1 the version number uses four numbers.
Major version, minor version, revision and build number.
XLINK 4.61A - 2007-Dec-10
- Starting with XLINK 4.61A the .dll version of xlink is no longer
available.
XLINK 4.59P - 2005-09-28
XLINK 4.55H - 2003-05-13
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
XLINK 4.52A - 2000-10-20
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
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
Known problems in Current Version
- 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.
- EW18364 When generating output
in the ELF/DWARF output format for the H8 processor, XLINK fails
to generate correct debug information for variables placed in
BIT-memory. It is not possible to inspect or modify such variables
through its name in a debugger.
Program Corrections and Updates
XLINK 6.5.0.91 - 2017-Apr-11
Fixed known problems:
- EW430-1454 When generating
output in the ELF/DWARF output format for the MSP430 processor,
XLINK terminates with an internal error. This problem was
introduced when the ICC430 compiler introduced
the __code20 memory attribute in ICC430 6.50.
XLINK 6.4.6.89 - 2016-Jun-21
Fixed known problems:
- EW26111 When performing stack usage
analysis and the program contained undefined externals, XLINK
could terminate with an internal error. This problem was
introduced in XLINK 6.4.5.88 (2016-Jun-20).
XLINK 6.4.5.88 - 2016-Jun-20
Fixed known problems:
- EW26109 When performing stack usage
analysis, references to content that is not included generates
(warning Ls014). This can only
happen for incorrect stack usage information (basically the
stack usage information claims to reference function X, but
function X is not present in the program).
XLINK 6.4.4.85 - 2016-Apr-08
Fixed known problems:
- EW26021 Certain combinations of
asian characters in the name of the directory containing an
input file could cause XLINK to fail to open the input file
(error 12). This problem was introduced
in XLINK 6.4.3.84 (2016-Feb-18).
XLINK 6.4.3.84 - 2016-Feb-18
Fixed known problems:
- EW25939 When generating output in
the UBROF output format and the input files
contains NOALLOC content, XLINK always produces UBROF
10 output without any NOALLOC content. The expected
output for NOALLOC content is UBROF 11.
Changes:
XLINK 6.4.2.83 - 2015-Dec-14
Fixed known problems:
- EW25846 When generating output in
the ELF/DWARF output format, local variables are erroneously set
to live until the end of the lexical block, this results in
incorrect debug information where several variables seemingly
resides in the same location. This problem was introduced
in XLINK 6.3.4.78
(2015-Sep-22).
XLINK 6.4.1.81 - 2015-Nov-06
Changes:
XLINK 6.4.0.80 - 2015-Nov-06
Fixed known problems:
- EW25780 When generating the maximum
call chain report (found in the linker list file) for stack
usage, XLINK can spend a significant amount of time before
terminating with an internal error. This can happen when an
empty segment part (typically the result of an RSEG
assembler statement that contains no actual content) contains
stack usage information. This problem was introduced with stack
usage in XLINK 6.2.0.62
(2015-Feb-11)
New features:
- Empty segment parts with stack usage information (this used to
trigger the EW25780 problem) now generate
warning 83. The stack usage
information in such segment parts will be ignored.
- When generating checksums, mirroring/reflection of input bytes
and the final checksum value can now be individually controlled
with the new a and z checksum flags.
See Independent
mirroring for the details.
- XLINK can now output a checksum summary that is compatible with
the Rocksoft^tm Model CRC Algorithm presented in section 15 of
A painless guide to crc error detection algorithms in the
linker list file. The new summary is activated by specifying
the r flag in an -x
option. See Rocksoft
Model CRC summary for the details.
XLINK 6.3.4.78 - 2015-Sep-22
Fixed known problems:
- EW25536 When outputting stack usage
information in the linker list file, local functions are only
described with their name instead of name and module. This
problem was introduced with stack usage
in XLINK 6.2.0.62 (2015-Feb-11).
- EW25592 When generating more than
one UBROF output file and generating additional output (-O) in
one of the simpler output format (including, but not limited to,
intel-hex and motorola s-records), XLINK fails to correctly
generate filler bytes for COMMON segments.
- EW25659 XLIB does not correctly
handle UBROF-files that contain stack usage information and
terminates with an "Unknown tag: E2" error message. This problem
was introduced with stack usage in XLIB
6.2.0.62 2015-Feb-11.
- EW25695 When generating output in
the ELF/DWARF output format, XLINK does not handle the debug
information for variadic functions correctly. The function is
not output as being variadic and the first non-parameter
variable in a variadiac is erroneously output as a formal
parameter. The exact effect this has depends on the debugger, in
many cases it has little or no effect.
- Output in the ELF/DWARF output format for MSP430 processor
now works better in the TI CCS debugger. The recommended
setting for CCS is now -yspco.
XLINK 6.3.3.74 - 2015-Jun-05
Fixed known problems:
- EW25470 When running under the Embedded
Workbench, XLINK does not generate dependency information for
.xcl-files. Changes to a .xcl-file are not detected and do not
trigger a rebuild as expected. This problem was introduced in
XLINK 6.3.2.73 (2015-May-26).
XLINK 6.3.2.73 - 2015-May-26
Fixed known problems:
- EW25446 When performing stack usage
analysis, XLINK terminates with an internal error if no entry
point (-s) has been specified. This problem was introduced
in XLINK 6.2.0.62 (2015-Feb-11)
- EW25447 When performing stack usage
analysis and specifying a local function in another module in
the .suc file (local_function [module_name]), XLINK
uses the current module (the module containing the function
performing the call) instead of the specified module. This can
result in incorrect information (the wrong function is used) or
in an internal error. This problem has no effect on the
generated code. This problem was introduced in
XLINK 6.2.0.62 (2015-Feb-11)
- EW25448 When performing stack usage
analysis and a possible calls directive for a function
that contains only indirect references specified no possible
targets (possible calls function_name : ;), the
function is treated as having no stack usage information instead
of performing no calls. This generates a spurious warning
(Ls014) for the function in
question. This problem was introduced in
XLINK 6.2.0.62 (2015-Feb-11)
XLINK 6.3.1.71 - 2015-May-18
Fixed known problems:
- EW25431 When linking input files
that use UBROF 11.0.1 (only the latest release of MSP430 uses
11.0.1) and the module contains stack usage information for
interrupt functions, XLINK erroneously generates the corrupt
input file error. This problem was introduced in
XLINK 6.3.0.70 (2015-May-13).
XLINK 6.3.0.70 - 2015-May-13
Fixed known problems:
- EW25394 When producing a module
summary in the linker list file (-xe) the value of N/A
(alignment) can become negative if the
--segment_mirror option is used with the @-modifier on
a segment with content. This is an incorrect sum in the linker
list file and has no effect on the generated code. This problem
has been present since the introduction of
--segment_mirror in XLINK
5.4.0.28 (2012-Jun-13).
New features:
- Stack usage analysis now supports more than one stack (this is
currently limited to the AVR processor). See
Stack Usage
Analysis for the details.
- XLINK now supports ELF/DWARF output for the MSP430
processor. See ELF details for
the details.
XLINK 6.2.2.68 - 2015-Apr-17
Fixed known problems:
XLINK 6.2.1.66 - 2015-Mar-03
Fixed known problems:
- EW25254 When checking the MISRA C
rules for the 8051 processor in the banked memory model, XLINK
spuriously generates error
149 (symbols should be static if possible) for all externally
visible functions. Such functions will trigger the MISRA C error,
even though they are called from other modules and thus cannot be
made static.
- EW25256 When
performing Stack Usage Analysis for
a program that contains ASEG or ORG assembler
statements, XLINK terminates with an internal error.
XLINK 6.2.0.62 - 2015-Feb-11
New features:
XLINK 6.1.4.59 - 2015-Jan-20
Fixed known problems:
- EW25164 When generating the MISRA C
warning about identifiers that differ only beyond the 31:th
character (error 148), XLINK
generates the MISRA C 2004 diagnostic (rule 5.1) in MISRA C 1998 and
the MISRA C 1998 diagnostic (rule 11) in MISRA C 2004.
- EW25167 When generating an
arithmetic checksum with the W or L flag (16- or 32-bit checksum
unit size), like -J2,sum,W, the flag is ignored and an 8-bit
checksum unit size is used.
- EW25175 When generating filler
bytes for the XDATA segment type for the 8051 processor,
XLINK can generate spurious filler bytes in XDATA-segments that are
used as RAM. This typically results in subsequent errors
like warning 28 (only parts of
the segment is initialized) and error
133 (the output format does not support multiple address
spaces).
XLINK 6.1.3.56 - 2014-Sep-24
New features:
- A new command line option, --output_checksum_summary,
has been introduced. When specified checksum information
is displayed together with memory usage in the summary of the link job.
See the Recent Manual Updates
file for the details.
XLINK 6.1.2.53 - 2014-Jun-27
Fixed known problems:
- EW24777 The -N (force
root) and -X (force noroot) command line options do not
work correctly. This problem has been present since the introduction
of the -X option in
XLINK 5.6.0.36
- EW24793 When generating output in
the ELF/DWARF output format, XLINK can generate an output file where
the debug information for some function parameters is incorrect if
the function in question uses function local enum constants. Such
parameters will be labeled as being variables instead of paramters.
The exact effect of this depends on the debugger. In many cases it
will have no effect.
New features:
- A new error, error 191 has
been introduced for when more than 2 gigabytes of fill is
requested.
XLINK 6.1.1.52 - 2014-May-12
Fixed known problems:
- EW24687 When generating output in the
UBROF output format and using the -Q option with different segment
types for the two segments, XLINK can generate a file that causes
the C-SPY debugger to terminate with an internal error. This
problem was introduced in XLINK 6.1.0.51.
XLINK 6.1.0.51 - 2014-Apr-17
Fixed known problems:
- EW24644 When the -k (disable
sorted output) and -Q (copy initialization setup) options
are used together, the simple ROM-formats (this includes, but is
not limited to, intel-standard, intel-extended and motorola
s-records) output the initializer part on the address immediately
after the initialized part instead of on the initializer part's
designated address. This problem has been present since the
introduction of -Q in XLINK 4.51K (1999-Aug-24).
New features:
- A new error, error 190, has
been introduced for when a -h command lacks a
range. -h(CODE) was accepted as an option, but it had no
effect as it lacked a range.
XLINK 6.0.3.49 - 2014-Apr-01
Fixed known problems:
- EW24560 When generating output in
the ELF/DWARF output format for the AVR32 processor, XLINK fails
to handle register pair variables correctly. This problem was
introduced in XLINK 5.8.0.42.
- EW24611 When generating output in
the ELF/DWARF output format, XLINK can terminate with an
internal error when generating the .debug_pubnames
section. This problem was introduced in
XLINK 5.8.0.42.
New features:
- A new error, error 189, has
been introduced for when an empty segment could not be placed. The
new error replaces error 16 (segment too long) for empty
segments.
XLINK 6.0.2.48 - 2014-Mar-07
Fixed known problems:
- EW24539 When defining weak symbols
using the -Dsymbol=?=value syntax introduced
in XLINK 6.0.1.47 (2014-Mar-03) such
symbols are not available to other command line options.
XLINK 6.0.1.47 - 2014-Mar-03
New features:
- It is now possible to define weak symbols using the -D
option with =?=. -DMY_WEAK_SYMBOL=?=MY_VALUE A
weak definition is only used if a normal definition does not exist.
See the Recent Manual Updates
file for the details.
XLINK 6.0.0.46 - 2014-Feb-28
Fixed known problems:
- EW24489 When using segment fill,
XLINK erroneously generates filler bytes for DATA-segments if they
are of the type NEARDATA (and only the
type NEARDATA). This problem was introduced in XLINK
5.2.3.14 (2011-Sep-01).
- EW24490 When generating output in
the ELF/DWARF output format for the RL78 and AVR32 processors, XLINK
can fail to generate location information for variables (typically
function arguments). This can result in such variables not being
displayed correctly in the debugger.
New features:
- XLINK is now able to generate UBROF 11 output. UBROF 11 is
generated if the input files contain features that require
UBROF 11 or on demand (-Fubrof11 or -rt,11).
See the Recent Manual Updates
file for the details.
- XLINK now supports NOALLOC content. You need a
compiler/assembler and a C-SPY that that also supports NOALLOC
to be able to use NOALLOC.
See the Recent Manual
Updates file for the details.
- The support for logging is no longer
experimental. See the Recent
Manual Updates file for the details.
- New errors have been introduced for the now unsupported
processors/options/output
formats. See the Recent Manual
Updates file for the details.
Removed functionality:
- The 740 target processor is no longer supported. This affects
all versions of the 740 compiler / assembler.
- The 6502 target processor is no longer supported. This affects
all versions of the 6502 compiler / assembler.
- The old 8051 target processor is no longer supported. This
affects version 5.x and lower of the 8051 compiler /
assembler. IAR tools for the new 8051 (that uses the XLINK
processor-id x51), version 6.x and higher, are not
affected.
- The 65k/65000 target processor is no longer supported. This affects
all versions of the 65k/65000 compiler / assembler.
- ELF/DWARF output no longer supports the ARM processor. The
ARM-specific ELF/DWARF format variants a (ARM-compatible
output) and r (relocatable output) are no longer
recognized as format variants.
- The RX target processor is no longer supported. This affects
the 1.x version of the RX compiler. 2.x does not use
XLINK.
- Relocation areas (-V) is no longer supported.
- The COFF output format is no longer supported. This does not
affect the XCOFF78K output format.
XLINK 5.8.0.42 - 2013-Dec-06
Fixed known problems:
- EW24254 When generating output in the
ELF/DWARF output format for the RL78 processor, XLINK terminates
with a corrupt input file error if one or more object files are
compiled using the --workseg_area compiler
option.
- EW24343 When placing empty segments
(0 bytes) in an empty (0 byte) placement range (this can be
achieved using the START:+SIZE notation), XLINK erroneously
generates error 16 (segment too long) even though the segment
actually fits.
- The html-files in the XLINK-distribution now all use the
extension .html (some files used .htm earlier).
New features:
XLINK 5.7.1.40 - 2013-Oct-08
Fixed known problems:
- EW24219 When generating output in the
ELF/DWARF output format for the AVR32 and the RL78 processors,
XLINK generates corrupt debug information for variables located on
the stack. This can lead to erroneous variable information and
DWARF-reader crashes.
XLINK 5.7.0.39 - 2013-Jun-28
Fixed known problems:
- EW23871 When filling two or more
memory areas using the private fill string version of the -h
option, XLINK fails to use the specified private fillstring for
all but one of the options, instead the general fill string is
used. This problem was introduced together with private fill strings in
XLINK 5.3.0.22
- EW24019 When generating output in the
simple-code output format, XLINK does not translate addresses if
address translation (-M) is used. This problem has been present
since the introduction of the simple-code output format
in XLINK 4.59E (2004-Sep-15).
New features:
- A new option, --threaded_lib, has been introduced. This
option makes it possible to use your application with a library
that has been prepared for threaded use (for more information
about threaded libraries, see the IAR Compiler Reference Guide).
See the Recent Manual
Updates file for the details about this option.
XLINK 5.6.0.36 - 2013-Apr-02
- EW23750 When generating the 'segment
did not fit' error message, XLINK terminated with an internal
error if the size of the allowed range was 0 (this can be achieved
using the START:+SIZE range notation).
- EW23860 When generating output in the
ELF/DWARF output format for the RL78 processor, XLINK produced a
corrupt .debug_frame section. This lead to incorrect
debug information for everything involving the call stack
(including the values of local variables in previous functions)
and could result in debuggers rejecting the file.
- A new experimental option, -X, has been
introduced. -X file.rxx results in all __root
content in all modules in file.rxx being treated as normal
content.
XLINK 5.5.0.33 - 2012-Dec-20
- EW23666 A new checksum flag,
x, that reverses the endianess of the computed
checksum has been introduced. See xman.html for the
details.
- A new error, 183 (-xo not
supported for this processor) has been introduced. See
the Recent Manual Updates file for the
details.
XLINK 5.4.1.30 - 2012-Sep-07
- EW23464 When calculating the checksum
for a segment using the {segment} syntax introduced in
XLINK 4.61L, XLINK terminated with an
internal error if the segment was empty (0 bytes). Note that the
checksum for an empty segment is equal to the initial
value.
XLINK 5.4.0.28 - 2012-Jun-13
- When placing segments using the packed segment placement option
(-P), XLINK is now more restrictive when merging segments. In
previous versions the segments
in -P(CODE)CODE_SEG=1000-7FFF
and -P(CONST)CONST_SEG=8000-8FFF could be merged. They
will now no longer be merged as CONST_SEG's possible
addresses differ from CODE_SEG's. This change only
affects how segments are listed in the linker list file, there
are no changes to assigned addresses or the generated
code.
- A new linker option, --segment_mirror, that supports
that a memory area can be accessible through more than one
address, has been introduced. See the XLINK manual for the
details.
XLINK 5.3.2.26 - 2012-Mar-30
- EW23129 When generating output in the
ELF/ DWARF output format, XLINK output the type of the function
instead of the return type of the function. This problem has been
present in XLINK since the introduction of ELF/DWARF
output.
XLINK 5.3.1.24 - 2012-Mar-02
- EW23023 ELF/DWARF output for the
78000 processor did not work correctly. XLINK either terminated
with a spurious error 113 (corrupt input file) or produced a
corrupt output file.
XLINK 5.3.0.22 - 2012-Feb-09
- EW23000 When linking object files for
the banked code model for the 8051 processor, XLINK could
erroneously link in modules that were not needed. This problem was
introduced in XLINK 5.2.6.19.
- EW23001 When generating output in the
basemap output format, non absolute symbols are no longer output
as absolute symbols. Outputing absolute symbols in this way
resulted in problems with weakly defined symbols when using the
basemap.
- EW23002 When generating the overlay
map part of the linker list file (-xo), XLINK could terminate with
an internal error if the linked program contained function
names with more than 320 characters.
- EW23003 XLINK now supports the use of
a checksum unit length larger than 8 bits. This can be used to
make the linker generated checksum match the one computed by
special CRC hardware that calculates checksums in this way. See
the checksum part
of xman for the
details.
- EW23004 When linking EC++ object
files for the banked code model for the 8051 processor, XLINK
could terminate with an internal error if the linked program
contained C++ functions. This problem was introduced
in XLINK 5.2.6.19.
- It is now possible to specify a fill string, as well as a fill
range, in the -h option. This enables the use of different fill
strings for different ranges. See the fill part
of xman for the
details.
XLINK 5.2.6.19 - 2011-Dec-06
- EW22857 When generating output in
the xcoff78k output format, XLINK terminated with an internal
error if any input file contained any kind of debug information for
the types long long or unsigned long long.
- Automatic selection of _Printf and _Scanf
implementations now works correctly for systems with banked code
models. As a consequence of this redirection of external
references (-e) now works better in the same cases.
XLINK 5.2.5.17 - 2011-Oct-24
- EW22769 When performing automatic
selection of _Printf and _Scanf implementations,
XLINK failed to correctly set up the static overlay system for the
automatically selected functions. This resulted in those functions
having an auto storage area with an undefined address. This
problem has been present since the introduction of automatic
selection in XLINK 5.2.0.10.
XLINK 5.2.4.16 - 2011-Oct-07
- EW22687 When producing additional
output files with the -O option and the specified file extension
contained a ".", the actually used extension began with the last
specified ".". Example:
-Ointel-extended,3(XDATA)=.eeprom.hex
The expected behavior
is that the filename should end with ".eeprom.hex". The actually
used ending was ".hex". This problem was introduced
in XLINK 5.2.0.10.
XLINK 5.2.3.14 - 2011-Sep-01
- EW22622 When generating segment
fill (-H or -h), XLINK could fail to generate fill if an empty
segment had an alignment greater than 1 byte.
- EW22634 When generating output in
the intel-extended output format with 20-bit segmented addresses,
XLINK could fail to generate a new data record if a 64k page
boundary was crossed in a data record. This resulted in bytes that
should have been placed in the next page being placed at the start
of the original page.
- When performing automatic selection of _Printf
and _Scanf implementations (introduced
in XLINK 5.2.0.10), XLINK now correctly
handles the relatively rare case of a reference to a function that
has alternatives but no requirements.
- Output in the ELF/DWARF output format for the 78K0R processor
now uses the official ELF
machine constant, 199.
XLINK 5.2.2.13 - 2011-Jul-07
- EW22522 When a custom CRC-polynomial
was specified in the -J option (like -J2,crc=8008), XLINK
erroneously generated error 106 (syntax error or bad argument). This
problem was introduced in XLINK 5.1.1.9 when
attempting to fix EW22292.
- When automatically selecting _Printf
and _Scanf implementations (see XLINK
5.2.0.10) XLINK now produces error 113 (corrupt input file) if a
non public function has alternatives.
- Experimental ELF/DWARF support for RL78 and
78K0R. See the Recent
Manual Updates file for the details.
XLINK 5.2.1.11 - 2011-May-27
- EW22456 When generating the error
message for error 177 (no definition provides all needed features),
XLINK could terminate with an internal error. This problem was
introduced in XLINK 5.2.0.10.
XLINK 5.2.0.10 - 2011-May-23
- EW22437 When generating output in
the UBROF output format and the program contained code segments that
had been specified in a -Q command, XLINK could generate
spurious mode change information. This had no effect on the
generated code but could lead to some code in the segment being
disassembled as data and some data in the segment being disassembled
as code when the program was debugged using the C-SPY debugger.
- EW22438 When linking a mix of C and
C++ modules where an enum type was used more than once in
the signature of a function and that function was called from a
module written in the other language, XLINK could erroneously
generate warning 6 (type conflict).
- XLINK now supports automatic selection of _Printf
and _Scanf implementations that satisfies the requirements
of the program. Automatic selection requires support in the compiler
and in the library. Consult your compiler manual to see if your
compiler / library supports automatic selection. When no function
satisfies all the requirements error
177 is generated. Automatic selection can always be disabled by
using the -e option to manually select a function. When
automatic selection is active, the linker list file lists which
function that was chosen.
XLINK 5.1.1.9 - 2011-May-03
- EW22292 When the checksum command
(-J) was used, XLINK failed to parse the arguments after the
algorithm specifier if the algorithm was immediately followed by a =
(example: -J2,crc16=START-END).
- EW22436 When producing output in
the UBROF output format, XLINK produced a corrupt output file if the
program contained COMMON segments that were specified in
a -Q command.
XLINK 5.1.0.8 - 2011-Feb-23
- EW22266 Problem
EW22059 was not correctly fixed in XLINK
5.0.2.5. In rare cases involving small (size < alignment)
segment parts being placed at the end of an address range, XLINK
could locate the segment part outside of the allowed range. This
could result in spurious segment overlap errors and/or in content being
placed outside of specified ranges.
- XLINK now supports the Renesas RL78 processor.
- XLINK no longer supports Relay Function Optimization. If object
files that require Relay Function Optimization are
encountered error 176 will be
generated. If you need to use Relay Function Optimization (only if
you use an ICCARM compiler with a version number in the range
3.41-4.42) you have to use an older version of XLINK (the 5.0-series
or older).
- XLINK no longer supports banked segment placement (-b). If the
-b option is encountered error 175
will be generated. If you want to continue using the latest version
of XLINK you need to use the packed segment placement command (-P)
instead.
XLINK 5.0.2.5 - 2010-Nov-05
- EW21778 When generating output in
the UBROF output format, XLINK could terminate with an internal
error if a COMMON segment was duplicated using
the -K option. This problem was introduced
in XLINK 4.61S.
- EW22046 When doing
FAR-segment placement (using a -Z segment placement command
whose segment type begins with "FAR", like
-Z(FARCODE)), XLINK could terminate with an internal error
if the placed segments had the segment type
CODE or FARCODE in the input file. This problem
was introduced in XLINK 4.61T.
- EW22047 When an address that would
have been negative was specified (this can be achieved through the
use of address
expressions), XLINK terminated with an internal error.
- EW22059 When doing packed segment
placement (-P), generating filler bytes (-H or -h) and the placed
segment contained segment parts with a size that was not a multiple
of the segment part's alignment, XLINK could fail to generate filler
bytes for the alignment gap. The alignment gap could contain
undefined bytes which could result in a checksum computed by the
program not matching the checksum computed by XLINK.
- EW22072 When not building an
application for use with the C-SPY debugger (not using
the -r command line option) XLINK could still include
symbol definitions from the runtime library intended only for use
with C-SPY, instead of generating an undefined external error, as
expected, when the application did not otherwise include definitions
for the needed symbols. The most common such symbol
is __write. This problem was introduced
in XLINK 4.61L.
- A new warning, 75 (The
program does not contain any content), has been introduced,
see the Recent Manual Updates file for the
details.
XLINK 5.0.0.2 - 2010-Jun-15
- The XAR och XLIB executables did not have a version resource in
the 5.0.0.1 release.
- XLINK is now better integrated in IAR Infocenter.
XLINK 5.0.0.1 - 2010-May-17
- EW21707 When producing output in the
ELF/DWARF output format for the M16C and M32C processors, XLINK
produced an output file that could lead to problems when debugged
with a Renesas debugger. The problem was introduced
in XLINK 4.61O when new ELF machine constants
were introduced. XLINK will now use the same ELF machine constants
as it used before XLINK 4.61O. See
the Recent Manual
Updates file for details about ELF machine constants.
- The -! option (old style comment) is no longer
recognized as an option. Use // or /* */
comments instead.
XLINK 4.61T - 2010-Feb-02
- EW21526 When generating output in the
xcoff78k format, XLINK could generate incorrect output or
terminate with an internal error when statement information was
generated for data declarations in assembler files.
- EW21568 When placing code segments
using FAR placement (-Z(FARCODE)), XLINK failed to honor
the NOREORDER (also known as keep-with-next) segment part
property at page boundaries. Some content in a sequence could be
placed on one side of the page boundary and some on the other even
though all of it should have been placed in one contiguous chunk
in one page. This problem was introduced in XLINK 4.51F
(1999-Feb-02).
- It is now possible to specify the exact order of the bytes in a
checksum command. See the
Recent Manual Updates file for the details.
XLINK 4.61S - 2009-Dec-09
- EW21451 When generating a checksum
(-J), XLINK could in rare cases terminate with an internal
error.
- EW21474 When generating output in the
UBROF output format, XLINK failed to generate debug information
for typedefs. This problem was introduced in
XLINK 4.61M.
- When producing output in the ELF/DWARF output format for the
RX-processor, XLINK could produce corrupt code sections when the
size of the code section was not a multiple of 4.
- When command line segment alignment
(-Z(SEGTYPE)SEGNAME|ALIGNMENT|) was specified for a
segment for which there were no segment parts, XLINK terminated
with an internal error.
- A new error, 172 (bi-endian code
segment not aligned) has been introduced. See
the Recent Manual Updates file for the
details.
- A new warning, 74 (least
significant bit in crc polynomial not set) has been introduced,
see the Recent Manual Updates file for the
details.
XLINK 4.61R - 2009-Oct-16
- XLINK 4.61Q was built using the wrong version
number in the version resource.
XLINK 4.61Q - 2009-Oct-14
XLINK 4.61P - 2009-Sep-14
- EW21232 When downgrading output from
UBROF 9 or 10 to UBROF 8 or lower and at least one row number
exceeded 65535 XLINK terminated with an internal error. This now
generates the new warnings 72
and 73. Source level debugging
will not be available for the affected functions. Assembly level
debugging and variable information will still be available.
- EW21296 When generating output in the
IEEE-695 output format for the NEC 78k0R processor, XLINK could
terminate with an internal error if any variable in the program
resided in a register.
XLINK 4.61O - 2009-Jul-02
- EW21147 When generating output in the
UBROF output format XLINK could, in rare cases involving C++
templates, generate a corrupt file that caused the C-SPY debugger
to abort while reading the file. This problem was introduced
in XLINK 4.61M.
- EW21149 When generating more than one
UBROF file, XLINK could generate spurious error 133 (The output
format cannot handle multiple address spaces). This problem was
introduced in XLINK 4.61K.
- A new warning, 71 (-! option
encountered), has been introduced. Support for -! (old style comment)
will eventually be removed from XLINK. Use /* */
or // for comments in .xcl-files.
XLINK 4.61N - 2009-May-04
- XLINK now supports the Renesas RX processor.
XLINK 4.61M - 2009-Apr-24
- EW19453 When generating output in the
COFF output format for the PIC processor, XLINK used byte
addresses instead of word addresses for segments declared using
the ASEG assembler directive.
- EW20909 was corrected in
XLINK 4.61L but was not listed in the
release notes.
XLINK 4.61L - 2009-Mar-06
- EW20735 The attempt
in XLINK 4.61K to
solve EW20735 was not completely
successful. The information about the enums did not contain the
size of the underlying type.
- EW20881 When generating output in the
xocff78k output format and a data segment (a segment that does not
contain object code) contained statement information, XLINK
generated a corrupt output file that was rejected by the
debugger.
- EW20885 It is now possible to
checksum segments by using them in the checksum command. See
the Recent Manual
Updates file for the details.
- EW20887 When generating output in the
raw-binary output format, XLINK could generate a very large
(exceeding 4 gigabytes) output file if the linked program
contained overlaps between segments with content. Now exactly one
of the segments will be used to decide the values of the bytes on
the overlapping addresses.
- EW20909 When generating output in the
ELF/DWARF output format for the Coldfire processor, XLINK
terminated with an "illegal ELF-register" error message if the
debug information for the object files used register
pairs.
- 2 new errors, 170 (checksummed
segment is not defined) and 171
(checksummed segment is packed), and 1 new
warning, 70 (segments with
content overlaps in a raw-binary file) have been
introduced.
- When linking modules that contain a very large number (tens of
thousands) of segment parts, XLINK now uses significantly less
memory.
- When linking input files that contain many (thousands) library
modules (compiled as library or defined in assembler
using MODULE), XLINK now uses significantly less
time.
XLINK 4.61K - 2009-Feb-04
- EW20735 When generating debug
information in the IEEE-695 output format, XLINK now correctly
outputs the name and value of enum constants.
- It is now possible to increase the alignment of a segment when
placing it by using |align (align start address)
or |align| (align start address and size) in a -Z
placement command. See the Recent Manual Updates
file for the details.
- 6 new errors, error162 (alignment
specification is not allowed for segment names here),
error165 (segment definition
uses an alignment that is too large),
error166 (code fill option must
be used for this processor),
error167 (bi-endian output is
not supported for this output
format), error168 (segment part
does not have the required alignment for bi-endian
output), error169 (code fill
requires all ranges to be closed) have been introduced.
- XLINK now supports generation of special kickstart files.
- The option summary of XLINK's signon message has been updated to
use [] for optional parameters.
- XLINK, XLIB and XAR now all have the same version number.
XLINK 4.61J - 2008-Dec-19
- EW20726 When generating the
.debug_pubnames section of the ELF/DWARF output fromat,
XLINK generated incorrect offsets for entries in the
section.
- The copyright notices of XLINK, XLIB, XAR and the html-files
have been updated.
- An experimental fill option, -hc, has been introduced. It
currently has no effect.
- 2 new errors, error 163 (Command
line symbol not defined) and error
164 (Neither number nor symbol) have been introduced. They are
generated instead of error 99
(Syntax error in segment definition) in relevant cases.
XLINK 4.61I - 2008-Oct-07
- EW20526 Error 123 (the format does
not support address translation) is now the
new warning 69. The
usual diagnostic control mechanism
can be used to turn this warning into an error or to suppress
it. See the Recent Manual Updates file for how this affects
the -M option.
- EW20536 When calculating a checksum
(-J), XLINK erroneously did not
include any bytes generated by other -J commands in the
calculation. This resulted in an incorrect checksum if the
checksummed range contained checksum bytes from other -J
commands. This problem was introduced in XLINK
4.60I.
- EW20547 When generating output in the
ELF/DWARF output format for the ARM processor, XLINK now generates
AEABI compliant call frame information.
- When generating the extra text for warning 6 (type conflict for
external) and warning 35 (more than one definition for
struct/union type) XLINK now outputs the module in which the type
was first encountered.
- When generating the static overlay map part of the linker list
file (-xo), stacks are now listed by name instead of by
number. Only stacks with non zero usage are listed.
- When generating a memory summary for the DSPIC processor, XLINK
now reports CODE memory usage in words as well as in
bytes.
XLINK 4.61H - 2008-Aug-20
- EW20189 When generating output in the
UBROF5 output format, XLINK could erroneously generate error 62
(File name used for multiple files) if a source file contained
more than one module. This could only happen for assembler
files.
- EW20321 When generating output in the
ELF/DWARF output format for the AVR32 processor, XLINK erroneously
claimed that an input file was corrupt if the input file contained
debug information for variables that resided in more than one
register (typically only long long and double
variables reside in more than one register).
- EW20366 A new variant of the -z
option (treat segment overlaps as warnings),
-za, has been introduced
to ignore overlaps between absolute entries.
- EW20372 When generating output in the
ELF/DWARF output format, XLINK could erroneously tag function
local variables as parameters if the source code didn't name all
parameters (example: int foo(int a, float) ). This could
result in ELF/DWARF readers rejecting the file. This problem was
introduced in XLINK 4.61A with the
introduction of tagging of parameters.
- EW20373 When generating output in the
ELF/DWARF output format use of both the
-yb (no
.debug_pubnames section) and the
-yw (no
.debug_aranges section) format variants in the same link
job erroneously generated error 81 (Unknown flag in extended
format option). This problem was introduced in
XLINK 4.60K with the generation of the
.debug_pubnames section.
XLINK 4.61G - 2008-Jun-04
- EW18617 When generating the linker
list file and the HTML and entry list options were specified
(-xeh), XLINK did not output the entry list.
- EW20177 When generating output in the
ELF/DWARF output format for the M16C processor and the input files
contained debug information that referred to the A1:A0
register pair, XLINK erroneously claimed that the file used
illegal registers.
- EW20178 Three new variants for the -z
option (treat segment overlaps as warnings) have been introduced,
-zo, -zp
and -zs. See the
Recent Manual Updates file for the details.
- A new warning, warning 68, has
been introduced. It is generated when the new -zs option
is specified for a processor that lacks a dedicated
SFR-area.
- When linking code that used SFB/SFE on a packed segment (placed
using -P), XLINK could in rare cases fail to generate warning 12
(Using SFB/SFE in banked or packed segment).
XLINK 4.61F - 2008-May-12
- EW20145 In some rare cases involving
indirectly called functions, the C-SPY debugger could suffer an
uncontrolled termination when debugging UBROF files generated by
XLINK. This was caused by XLINK outputting an incorrect type for
indirectly called functions.
- The readme text for warning 23
has been updated.
XLINK 4.61E - 2008-Apr-14
- EW20019EW20019
was not fixed correctly in XLINK 4.61D. If a
byte that was associated with statement information was placed on
the address 0xFFFFFFFF, XLINK terminated with an internal
error.
XLINK 4.61D - 2008-Apr-12
- EW20016 When generating output in the
xcoff78k output format, XLINK terminated with an internal error
when generating statement information for compiler generated
functions.
- EW20019 When generating output in the
ELF/DWARF and IEEE695 output formats for the AVR32 and R32C
processors, XLINK failed to generate statement information for
assembler files.
XLINK 4.61C - 2008-Mar-04
- EW19844 When generating additional
output files (-O) and the name was to be the same as the main
output file but with its own extension (example:
-Omotorola=.mot), XLINK did not add the extension if the
name of the main output file contained a '.' (example: -o
my_app_1.2.bin -Omotorola=.mot resulted in the output file
my_app_1.2 not the expected
my_app_1.2.mot).
- EW19939 When generating output in the
ELF/DWARF output format and the strip source file paths option
(-yx) was used, XLINK did not output the extension of the files in
the .debug_line section. This lead to debuggers being unable to
locate source files. This problem was introduced
in XLINK 4.61A with the LOCALE specific file
paths.
- XLINK is now LARGEADDRESSAWARE. In a system that is prepared for
this XLINK can now address 3 gigabytes of memory instead of the
normal 2. This is only relevant when linking very large projects
where the memory requirements can exceed 2 gigabyte. Consult Microsoft
for more details about what needs to be done for this to
work.
- XLINK now supports bytewise and mirrored initial values for
checksums. See the Recent Manual Updates
file for the details.
- Specifying an initial checksum value that is greater than the
maximum value that can be contained in the checksum now generates
the new error 161.
- XLINK now supports linking of protected files. A protected file
can only be successfully linked if a valid license can be found
for that file. Protected files currently (March 2008) include
only the IAR Power Pack object files. If one or more of
the protected files contain a license requirement that cannot be
satisfied, XLINK will generate the new error 160. License managment is
active only for protected files.
- The MISRA-C 2004 rules are now available in XLINK. MISRA-C 2004
does not introduce any new rules that are checked in XLINK, only
the rule numbers have been changed since MISRA-C 1998.
- Issue EW19764 was erroneously listed as
issue EW19568 in the release notes for XLINK
4.61B.
XLINK 4.61B - 2008-Jan-18
- EW19764 When generating output in the
UBROF output format and using the -n option (no local symbols),
XLINK removed all local function symbols referenced by the debug
information. If such symbols were removed the C-SPY debugger
failed to load the generated file.
The -n option now no longer removes local function symbols that
are referenced by the debug information. If debug information is
not present in the file the symbol will be removed as
normal.
- EW19827 When generating output in the
xcoff78k output format for the 78000 processor, XLINK generated
output files that were rejected by the NEC debugger. The output
generated for the 78K0R processor was not affected by this
problem. This problem was introduced in XLINK
4.61A.
- EW19828 A new format variant
modifier, -yb, has been
added to the ELF/DWARF output format. It is used to suppress the
generation of the .debug_pubnames section. This is useful if the
debugger is unable to read XLINK's .debug_pubnames section,
see recommended
ELF/DWARF settings for the details.
- EW19829 When specifying file specific
properties on input files using the -C (force library), -A (force
program) or -E (empty load) options, XLINK failed to locate the
file if the path was supplied via the -I option or the
XLINK_DFLTDIR environment variable. This problem was
introduced in XLINK 4.61A with LOCALE
specific file paths.
- EW19830 When generating additional
output files (the -O option) and the name of the outputfile was not
specified (like -OELF,axs), XLINK generated the additional output
file in the same directory that XLINK was called from, not in the
directory that was specified in the -o option.
Example:
xlink -f other_commands.xcl -o ..\MyFile.hex -OELF,axs
The expected behavior here is that XLINK should generate
MyFile.hex and MyFile.elf in the parent
directory. XLINK generated MyFile.hex there and
MyFile.elf in the current directory. This problem was
introduced in XLINK 4.61A with LOCALE
specific file paths.
XLINK 4.61A - 2007-Dec-10
- XLINK now supports LOCALE specific file paths.
- Starting with the 4.61A release XLINK is no longer compatible
with the EW23 and earlier release of the Embedded
Workbench. 4.60M is the last release that is compatible with
EW23.
- When generating debug information in the ELF/DWARF output format
for the ColdFire processor, XLINK produced erroneous stack
variable information (wrong register used as base).
- When generating debug information in the ELF/DWARF output format,
XLINK now specifies which of a function's local variables that
are parameters.
- When generating debug information in the ELF/DWARF output format
for the M16C processor, XLINK now produces files that work better
with the Renesas debugger.
- When generating output in the xcoff78k output format for the NEC
78K0R processor, XLINK now produces files that work better with
the NEC debugger.
- XLINK did not check for segment overlaps in space that was
allocated due to use of the -U (address sharing) option. These
are now detected and handled like any other segment
overlap.
- The segment overlap detection now works significantly faster in
cases where there are many (thousands) segments.
- The behavior of -I has been updated. The argument to -I is no
longer a semicolon separated list of path prefixes but a single
include path. See the Recent
Manual Updates filefor the details.
- Two new errors, error 158
(invalid directory name) and error
159 (invalid file name) have been added.
XLINK 4.60M - 2007-Oct-08
- EW19568When performing ARM/THUMB
relay function optimization and generating filler bytes (-H),
XLINK could in some cases terminate with an internal
error.
XLINK 4.60L - 2007-Sep-24
- XLINK now supports the Freescale ColdFire processor.
XLINK 4.60K - 2007-Aug-31
- EW19443 When linking object files for
the 8051 processor and the input files contained absolutely placed
data below address 0x20, XLINK could consider the entire
BIT-area to be occupied. This could lead to spurious e16
(Segment too large) errors.
- EW19449 When generating output in the
raw-binary output format, XLINK could in some cases produce a very
large (over 4 Gigabyte) output file. This problem was introduced
when EW18235 was fixed.
- When generating output in the xcoff78k output format for the NEC
78K0R processor, XLINK now produces files that work slightly
better with the NEC debugger.
- When generating output in the ELF/DWARF output format for the M16C
processor, XLINK used the wrong register number as the base register
for auto variables.
- XLINK's ELF/DWARF output has been updated. See the Recent Manual Updates file for the
details.
- EW19216 When linking object files
that contained a mix of COMMON segments with the same
name where some had content and some had not, XLINK could
terminate with an internal error.
- EW19217 When generating output in the
raw-binary output format, XLINK could erroneously generate error
133 (The output format cannot handle multiple address spaces) if
space was allocated in more than one address space. Now the error
is only generated if actual content is present in more than one
address space.
XLINK 4.60I - 2007-May-28
- EW19065 When generating output in the
xcoff78k output format for the 78K0R processor, XLINK did not emit size
information for far pointers. This could result in an incorrect
display of pointers in a debugger's watch window.
- When generating output in the UBROF and ELF/DWARF output formats,
XLINK will now generate an additional symbol for each checksum
symbol that contains the checksum's value, not its address. Please
consult the Recent
Manual Updates file for the details.
XLINK 4.60H - 2007-Apr-24
- EW19053 When generating output in the
ELF/DWARF output format, XLINK could in some cases generate
erroneous call frame information for relatively large
functions. This could lead to an incorrect call stack display in
debuggers.
XLINK 4.60G - 2007-Mar-30
- EW18764 When checking for segment
overlap for processors where BIT memory shares an address
space with non-bit memory, XLINK could terminate with an internal
error if the address space only contained BIT variables
and segments.
- EW18808 When generating output in the
xcoff78k output format for functions that contained inline
assembler statements and were compiled with version 4.x of the
ICC78k compiler, XLINK generated corrupt debug information for
those functions.
- EW18899 In rare cases involving
definitions/declarations of a variable using different top-level
typedefs in different modules, XLINK could terminate with an
internal error during type unification.
- EW18988 When linking input files
that contained absolute segments (ASEGN), XLINK always
treated these as if they had the ROOT attribute. Such
segments were always included in the output even if they were not
needed.
- EW18989 When linking input files
that contained absolute segments that resided in BIT
addressable memory, XLINK could fail to reserve enough memory in
the BIT address space if the absolute segment was larger
than 1 byte. This could lead to overlaps between the absolute
segment and BIT segments.
- XLINK now supports the Renesas R32C processor.
XLINK 4.60F - 2007-Jan-16
- EW18559 When generating output in the
ELF/DWARF output format for object files produced with the
--preinclude compiler option, XLINK could terminate with
an internal error if the preincluded file was completely empty (0
bytes). This problem was introduced with the fix for EW18532.
- EW18730 When generating output in the
MPDS-code output format and using the -YA format variant modifier
(produce a raw-binary file instead of a MPDS-code file), XLINK
erroneously produced a completely empty file (0 bytes). This
problem was introduced in XLINK 4.60B with
the ability to restrict output to a single address space in the
raw-binary output format.
XLINK 4.60E - 2006-Dec-07
XLINK 4.60D - 2006-Nov-20
- EW18532 When generating output in the
ELF/DWARF output format and using ARM compatible output (-ya), the
least significant bit in the address of all symbols was always
cleared. This should only be done for code symbols.
- EW18559 When generating debug
information in the ELF/DWARF output format, XLINK could produce an
incorrect name for a compile unit if it was compiled with the
--preinclude compiler option.
- EW18573 When generating output in the
intel-standard output format, XLINK could terminate with an
internal error if the restrict output to
a single address space format variant modifier (like
-y(CODE) or -Ointel-standard,(CODE)=file1) was
used. This problem was introduced in XLINK
4.60C.
- When the debug system option (-r) is used when a format type has
been specified (-F), XLINK now generates warning 33. Warning 33 was
disabled by misstake in XLINK 4.58A.
- When the debug system option (-r) is used and there are one or
more extra output files (-O), XLINK now generates the new warning 67.
XLINK 4.60C - 2006-Oct-13
- EW18360 The EW18360 problem was not fixed properly in
XLINK 4.60B so xcoff78k output for programs
containing partially initialized segments was still
corrupt.
- EW18446 When producing output in the
ELF/DWARF output format for the H8 processor (and only for this
processor), XLINK could produce incorrect statement
information. This could lead to an incorrect mapping between
addresses and source code.
- EW18469 When linking files for the
78000 processor, XLINK could erroneously consider the address
after absolutely placed constants and code with odd sizes
to be occupied. Nothing could be placed at, and no filler bytes (-H)
were generated for, such addresses.
- DWARF debug information for the H8 processor has been modified to
be compatible with the Renesas HEW debugger. The
.debug_aranges section of such files are not standard
(DWARF 2.0.0) compliant. Use the format variant modifier
w (-yw) to disable generation of the
.debug_aranges section if this is a problem.
XLINK 4.60B - 2006-Sep-06
- EW18216 When generating filler bytes
(-H) and a sequentially placed (-Z) segment was placed in a hole
left by a packed (-P) placement command, XLINK could erroneously
generate filler bytes that overlapped that segment.
- EW18235 When producing output in the
raw-binary output format and bytes were placed in more than one
address space, XLINK failed to terminate and began producing
an output file containing an unending sequence of zeroes.
- EW18346 When generating filler bytes
(-H) for segments that were placed using a packed segment
placement command (-P) and that placement command had two or more
nonconsecutive ranges, XLINK could fail to fill the entire
range. This problem was introduced in XLINK
4.60A.
- EW18360 When generating output in
the xcoff78k format and the program contained a segment that was
only partially initialized (example: a segment with a memory size
of 0x20 bytes where the object file only initializes the first 4),
XLINK produced a corrupt file were the sizes of the initialized
segment and the initializer section were switched.
- EW18361 When generating output in the
raw-binary output format and the input files contained absolute
code, XLINK failed to terminate and began producing an output file
containing an unending sequence of zeroes.
- EW18364 When generating output in the
ELF/DWARF output format for the H8 processor, XLINK failed to
translate the address of bit segments from bit addresses to byte
addresses. Also the size of such segments was given in bits
instead of in bytes. This could lead to debuggers rejecting the
file. Even with this problem fixed the debug information for
variables in bit segments does not work correctly, this is a new
known problem.
- EW18366 When producing output in the
ELF/DWARF output format, XLINK generated a .debug_aranges section
that did not comply with the DWARF 2.0.0 standard. This problem
was introduced with the introduction of the .debug_aranges section
in XLINK 4.59Q.
- Output in the raw-binary output format is now limited to a single
address space. Please
consult the
Recent Manual Updates file for details of how to generate
raw-binary output for several address spaces.
- ARM/Thumb relay functions are now listed as "shared" in the module
summary in the linker list file.
XLINK 4.60A - 2006-Jun-20
- EW18166 When producing output in the
intel-standard output format, XLINK produced an end of file record
containing a program entry point that was off by one and a corrupt
checksum. This problem was introduced in XLINK 4.59Z.
- EW18178 When performing type
unification for EC++-modules that contained a class that inherited
from a template of itself, XLINK could terminate with no error
message and no generated output.
Code example:
template <class T>
class A
{
T* data;
};
class B : public A<B>
{
};
- The previously ignored -m and -t options are no
longer recognized as options. See the Recent Manual Updates file for
the details.
XLINK 4.59Z - 2006-05-10
- EW18000 When generating output in the
IEEE695 output format, XLINK could terminate with error 119
(Cannot handle C++ identifiers in this output format) if the
program was compiled using a new (released during 2006) IAR
compiler and contained any interrupt function.
- EW18029 When generating output in the
intel extended output format and using segmented addresses (-Y0 or
-Y3), XLINK could generate records where the bytes of a data
record spanned a 64K page boundary. The bytes who's address in the
record would place them in a new page were actually placed in the
same page as the rest of the record but starting at address 0 as
the address is calculated modulo 64K. This could lead to several
bytes residing at the same address.
- EW18060 When generating output in the
simple-code output format and the input files contained segment
parts that resided in the REGISTER address space, XLINK
terminated with an internal error.
- EW18061 When generating output in the
simple-code output format, XLINK could not generate an output file
that contained only one address space when that was requested. The
file always contained all address spaces. This problem has been
present in XLINK since the introduction of simple-code in
XLINK 4.59C.
- EW18062 When performing ARM/Thumb
Relay Function Optimization and using packed segment placement
(-P) with filler bytes, XLINK could fail to generate filler bytes
correctly if all code in a segment placement command did not
have the same alignment.
- A new command line option, -zb, has been introduced. When -zb is
specified error 24 (segment overlap) is suppressed for segment
overlaps where at least one of the involved segments is a bit
segment.
XLINK 4.59Y - 2006-04-03
- EW17934 When linking files that
contained absolute assembler code, XLINK could sometimes fail to
produce debug information for that code. This problem was
introduced in XLINK 4.52C.
- EW17935 When producing output in the
MPDS-SYMB output format, XLINK could in rare cases terminate with
an internal error. This problem was introduced in XLINK
4.48A.
- EW17936 When producing relocatable
output in the ELF/DWARF output format, XLINK could spuriously
generate warning 64 (The address space used in the command is
incompatible with the address space of the ranges) if the address
ranges of one relocation area were
"inherited" from a previous relocation area. This problem has been
present since the introduction of warning 64 in XLINK
4.59R.
- EW17938 When linking object files
that contained BIT variables or references to empty segments,
XLINK could in some cases terminate with an internal error. This
problem was introduced with the fix for EW17820 in XLINK
4.59X.
- XLINK now supports the NEC 78K0R processor.
XLINK 4.59X - 2006-02-28
- EW17813 When performing ARM/Thumb
Relay Function Optimization, XLINK could terminate with an
internal error if the program contained segment parts of a segment
that wasn't named in a segment placement command and none of those
segment parts were needed by the program. This problem was
introduced in XLINK 4.59W with the fix for EW17773.
- EW17820 When doing packed segment
placement (-P), XLINK could spuriously generate error 24 (segment
overlap) if a sequential segment placement command (-Z) placed
segments in the same ranges as a -P command. This problem was
introduced in 4.59W with the fix for EW17774
.
XLINK 4.59W - 2006-02-08
- EW17707When generating output in the
ELF/DWARF output format for the HCS12 processor, XLINK could
terminate with an internal error if any variable resided in a
register pair.
- EW17741When doing packed segment
placement (-P), XLINK terminated with an internal error if at
least one packed segment was placed in an address space in which
no sequentially placed segment (-Z) segment was placed. This
problem was introduced in XLINK 4.59U with the fix for
EW17667.
- EW17773When performing ARM/Thumb Relay
Function Optimization, XLINK could terminate with an internal
error if an entire code segment was not needed.
- EW17774When using the filler bytes option
(-H) and a sequential segment placement command (-Z) placed
segments in a range into which a packed segment placement command
(-P) already had placed segments and the segments did not fit in
the available space, XLINK created filler segments that caused
spurious segment overlap errors (error 24).
XLINK 4.59V - 2006-01-31
- EW17601 When generating type information,
XLINK could in rare cases generate corrupt type information for a
symbol if it was defined in assembler code and was referenced from
C-code.
- EW17730 When doing packed segment
placement (-P), XLINK could generate spurious segment overlap
errors (error 24) in cases involving segment parts with a
size that wasn't a multiple of its alignment.
XLINK 4.59U - 2006-01-16
- EW17667 When doing packed segment
placement (-P), XLINK could generate spurious segment overlap
errors when an entire sequentially placed segment fit into an
alignment hole between two of the individual parts placed by the
packed placement.
- When performing Relay Function Optimization for the ARM/Thumb
processor, XLINK now detects if both the old and the new system
are used simultaneously and if so generates warning 65.
- When generating the error text for error 18 (range error), XLINK
now correctly reports the offset from the involved label rather
than the offset in the segment part.
- XLINK now supports the avr32 processor.
XLINK 4.59T - 2005-12-15
- EW17604 XLINK did not work correctly
when running under the IAR Embedded Workbench and generated an
"uncontrolled termination" error message. This problem was
introduced in XLINK 4.59S.
- EW17605 When generating the module
summary part of the linker list file (-xn), XLINK could terminate
with an internal error if the linked program contained only
absolute code.
XLINK 4.59S - 2005-12-13
- EW17534 When generating output for
the PIC family of processors and using the filler bytes options (-H
or -h), XLINK could spuriously generate warning 52 (More than one
definition for the byte at address address in common
segment segment.) if the program used fill in any
common segment.
- EW17586 When linking programs that
contained weakly defined symbols (PUBWEAK assembler labels or
non inlined instances of inlined functions) generated by the
ICC78000 compiler, XLINK could terminate with an internal error
("Address calculation needed to use an invalid address").
- EW17587 When generating output in the
motorola or intel formats (or other simple formats), XLINK no
longer starts a new record on an address immediately following the
last address in a record that did not specify content for all
bytes available to it.
- EW17589 When performing Relay
Function Optimization and using packed segment placement (-P) with
filler bytes (-H or -h), XLINK could fail to allocate filler bytes
for unallocated space at the start of a packed segment. This
could happen when the segment with the higher start address
also had a higher alignment than the previous one. In this case no
filler bytes were generated in the gap between the packed
segments.
- The time requirements of XLINK have been significantly reduced.
XLINK 4.59R - 2005-11-22
- EW17409 When generating checksums
(-J), it is now possible to specify the initial value of each checksum command. The initial value for
each checksum command is listed in the linker listfile.
- EW17430 When performing checksum
calculation using mirrored simple sum, XLINK failed to
mirror the bytes. This resulted in an incorrect checksum in this
case. This problem was introduced in XLINK 4.59E with the expanded
checksum calculation.
- EW17511 When generating debug
information for the new ICC8051 (version 6 and above), XLINK could
in some cases generate incorrect debug information for variables that
resided in more than 2 registers.
- EW17512
When a segment placement command inherited addresses from a
previous placement command, the address space was incorrectly
inherited as well. Example:
-Z(CODE)SOMECODE=1000-1FFF
-Z(DATA)SOMEDATA
In this case SOMEDATA was placed after SOMECODE
but in the CODE address space, not DATA address
space that was expected.
Generally it is not a good idea to inherit ranges from a placement
command in a different address space. This now generates warning 64.
The example above will now generate the warning and then place
SOMEDATA in the DATA address space but on the first
available address after the end of SOMECODE.
- EW17513 When doing segment overlap
control, XLINK could erroneously claim that two absolutley placed
bit variables overlapped if their bit addresses were mapped to the
same byte address.
- EW17514 When performing ARM/Thumb Relay
Function Optimization, XLINK could in rare cases terminate with an
internal error ("address calculation needed to use an invalid
address"). This problem was introduced in XLINK 4.59L when
EW16612 was fixed.
- A new format variant, -Y2, has been added for the intel-extended
format. It behaves like linear addresses (-Y1) in every way
except that the program entry record is not emitted.
XLINK 4.59Q - 2005-10-24
- EW16003 When linking input files that
were generated using the --char_is_signed compiler option and
generating output in the UBROF 8 or later output format, XLINK
generated output where the type information claimed that plain
chars were unsigned.
- EW16003-2 When performing the
list-object-code operation on absolute UBROF files, XLIB always
output type information where signed plain chars were listed
as unsigned.
- EW17355 When generating output in the
XCOFF78K format and generating additional output files (-O) in one
of the simpler output formats (like intel-hex or motorola), XLINK
could produce erroneous bytes in COMMON segments (usually used for
the interrupt vector) of the additional output files. This problem
was introduced in XLINK 4.58H.
- EW17356 When generating error 62
(Filename file used for multiple files), XLINK named the
file immediately preceding the multiply defined file on the
command line instead of the multiply defined one. This problem
was introduced in XLINK 4.59K.
- EW17358When performing segment
overlap control on segments placed using packed segment placement
(-P), XLINK could generate spurious segment overlap errors (error
24) if at least one segment part had a size that wasn't a multiple
of its alignment. This problem was introduced in XLINK
4.59O.
- EW17396 When lowering output to UBROF
5, XLINK could fail to set the correct UBROF revision on modules
created using the --image_input option.
- EW17403 When generating output in the
ELF/DWARF output format, XLINK generated corrupt DWARF information
for assembler modules. This problem was introduced in XLINK
4.59P.
- ELF/DWARF output has been updated with two new sections.
See xman for the details.
- When producing ELF/DWARF output, XLINK can now produce non
factored offsets for Call Frame Information if the -yo format
variant is specified. See xman for
further details.
XLINK 4.59P - 2005-09-28
- EW17136 When generating output in the
IEEE-695 output format, the debug information contained incorrect
offsets for bitfields whose base type was given as a
typedef.
- EW17228 When doing packed segment
placement (-P) and the input files contained sequences of
consecutive segment parts with mixed alignment, XLINK treated
those segment parts as if they had the highest alignment of any
segment part in that sequence. This wasted space and lead to
incorrect code when the code was fall through. This problem was
introduced in XLINK 4.58A.
- EW17275 When generating output in the
ashling, zax, msd-symb, pentica-a, pentica-b, pentica-c,
pentica-d, symbolic or typed output format, XLINK could
erroneously generate error 119 (Cannot handle C++ identifiers in
this output format) if the input files contained interrupt
functions.
- EW17312 When performing Relay
Function Optimization and doing packed segment placement (-P),
XLINK could fail to generate filler bytes to fill alignment gaps
between the last segment in a sequence of segments placed with -Z
placement commands and the first segment in a sequence of -P
placement commands. This problem has been present in XLINK since
the introduction of Relay Function Optimization in XLINK
4.58A.
- EW17313 When matching C++ names
across modules, enum types with the same name but different
definitions were previously considered different types. Now enum
types with the same name are always considered the same type for
this purpose. This should make any consequent problems manifest in
ways that are easier to understand.
- EW17314 When lowering output to UBROF
5, XLINK could erroneously set the UBROF revision field of
internal modules (like absolute entries and filler bytes) to
0. This problem was introduced in XLINK 4.59L.
- EW17321 When generating output in the
IEEE-695 output format, and not using the PDB30 format variant,
the debug information contained incorrect offsets for bitfields
for all targets using little-endian byte order.
- XLINK now supports output in the IEEE-695
output format for the 78000 processor.
- Address Translation (-M) is now available for the ELF output
format. See Address Translation for
more details.
XLINK 4.590 - 2005-08-18
- EW17057 When generating XCOFF78K
output for the 78000 processor, XLINK could terminate with an
internal error if the program contained static functions. This
problem was introduced with the stack usage functionality in XLINK
4.59N.
- EW17058 When a range error was to be
generated and there was no symbol involved (this usually only
happens for assembler code without PUBLIC labels), XLINK could
silently fail to emit the error. This could create the impression
that the linking process succeeded when it actually failed and the
end result could be an incorrect program. This problem was
introduced in XLINK 4.58C.
- EW17072 When doing packed segment
placement (-P) and using filler bytes (-H), XLINK generated
spurious segment overlap error messages when a filler byte was
generated in alignment holes inside a packed segment. This problem was
introduced in XLINK 4.58A.
- EW17079 When accessing the start
(SFB) or end (SFE) address of a packed segment from a program,
XLINK could fail to generate warning 12 (Using SFB/SFE on banked
or packed segment) if the last linked in module that made a
contribution to the segment contained an empty segment part. Under
the same circumstances the segment in question was listed twice in
the linker list file. Once as as part of packed segment (like
<SEGMENTNAME 1>) and once as sequentially placed segment
(SEGMENTNAME).
- EW17090 When linking files that
contained zero sized absolute segments, XLINK could fail to place
other segments at the address of the zero sized absolute segment
if the address of the absolute segment overlapped the bit memory
of the target processor. This problem was introduced in XLINK
4.59J.
- EW17118 When linking files containing
mode change information (this is currently only available in
ICCARM 4.30a) and generating output in older UBROF format (UBROF9
and lower), XLINK output the mode change information in that
format, even though there is no way to represent this information
in older UBROF formats. This lead to corrupt older UBROF files.
- When generating ELF/DWARF output for the ARM processor, XLINK now
outputs the special $a, $d and $t symbols if the input files
contain mode change information. Mode change information is
currently only available in files generated by ICCARM
4.30a.
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
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 the
Recent Manual Updates file 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 the Recent Manual Updates
file 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 the Recent Manual Updates
file 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 the Recent Manual
Updates file for further details.
- A new experimental feature has been added. XLINK is now capable of
producing an arbitrary number of checksums. See
the Recent Manual Updates file 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 cannot 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
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 the Recent Manual Updates file
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 the Recent Manual Updates file
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 linker list 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 the Recent Manual Updates
file 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 Release Notes 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
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".
The text for the 4.53 (and earlier) series have been removed from this file.
Copyright (C) 1987-2017 IAR Systems AB.