IAR Information Center for Arm

Important information
New features
Known problems
Program corrections
User guide corrections
Miscellaneous
Release history

Important information

If no heap handler has been set on the command line (the options --advanced_heap, --basic_heap, and --no_free_heap), or if Heap selection>Automatic has been selected in the IDE, the linker chooses the heap implementation differently than in previous versions of the product. This change can result in another heap handler being chosen. In product versions earlier than v.9.30.1, the advanced heap was always chosen if the user code referred to malloc/free, but now the basic heap is chosen instead if the majority of the linked modules are optimized for Size.
This can result in problems if your code refers to features in the advanced heap that are not available in the basic heap. The linker will try to load both heap handlers, causing error Li009: runtime model conflict: Module heap0.o(dl7M_tln.a) specifies that '__Heap_Handler' must be 'Basic', but module dlmalloc.o(dl7M_tln.a) has the value 'DLMalloc'.

New features

ELF Dumper JSON mode
- The ELF Dumper has several new options that enables it to produce its output in the JSON standard format.

Known problems

[EWARM-13116, TPB-3913] The linker option --image_input does not support filenames that contain comma characters (,).
Workaround: Rename the file so it does not contain comma characters.
[EWARM-12943, TPB-3893] When using the advanced heap, the heap function can fail to operate correctly if too little space is allocated for the heap. The minimum space required is 50 bytes. The default way to set up the heap is to allocate a block (typically called HEAP) in the .icf file and then use that space when the memory handler needs more memory, but there are many ways to set up a working heap.
To ensure that you have enough heap space allocated, you can use check that directives in the .icf file. One way to do that is place the heap handling symbols in its own block:

{{define block MallocBlock {
{ ro code symbol __iar_dlmalloc, ro code symbol __iar_dlfree }
;}}

and then use this directive:

check that (size(block MallocBlock) == 0 || size(block HEAP) >= 50);

The check succeeds as long as you have no heap handling functions, or you have at least 50 bytes of heap.

Note: The advanced heap is used if the option --advanced_heap has been specified or if the linker automatically chooses that heap.
[EWARM-10260, TPB-3668] When linking files using a configuration file where the range of a place in directive is split in two by a place at directive, the linker can in some cases fail to allocate sufficient space to a placement request, even though such space is available. This will generate an error that spuriously claims that there is not enough space.
[TPB-3867] If both code and data are placed in RAM, the relaxation that generates GP relative addresses can fail if the code is placed before the data.
Workaround: Disable relaxation or place the code after the data in RAM.
[TPB-3720] When placing an .icf block that has the fixed order property and whose content has a mix of alignments, the block's end address can be misplaced. Instead of ending at the highest address, the last address in the block can be placed at a lower address (up to the lower of the involved alignments).
Example: {{place at end of ROM
{ block CONTENT }
;}}
If ROM is a region from 0x0 to 0xFFFF, and CONTENT has a mix of alignments 4 and 8, the block CONTENT can end on address 0xFFFB instead of the expected 0xFFFF.

Program corrections

[TPB-3919] When linking applications where there are multiple overlapping ranges, and mirroring is active in one of those ranges, the linker can terminate with an internal error (Distributor::TraverseRanges - range overshoot) if compressed initializers are used.
[TPB-3915] Using the use init table directive in the .icf file in combination with C++ dynamic initialization or other extra initialization routines, causes the linker to produce a corrupt output file.
[EWARM-12976, TPB-3912] When generating checksums or parities, ielftool can terminate without giving diagnostics. This can happen if there is a 0-sized section located on address 0. Such a section is spuriously considered to cover the range 0x0-0xFFFFFFFF, and this seemingly contains all symbols with a 32-bit address (which in 32-bit ELF means all symbols). When the result of a checksum or parity operation is to be written to file, the empty section is used. This fails and the program terminates, and no output file is generated.
[TPB-3906] If a fixed size block has been specified in the linker configuration file, ielfdump can fail to stop disassembly at the end of the current section, leading to warning Ex008 and aborting the disassembly. If the application content does not fill the block, the linker inserts padding to reach the specified size. In this situation, disassembly can incorrectly continue into the padding.
[EWARM-12098, TPB-3850] When linking applications that contain code overlays, the linker fails to warn if one overlaid code section refers to another overlaid code section in the same RAM area. A code overlay is when code is linked to and executed in RAM, and more than one such code section is linked to the same RAM area. Only one such code section can be active at any given time.

User guide corrections

None.

Miscellaneous

None.

Release history

V9.60 2024-06-04/h4> Program corrections

In 9.60.3
[EWARM-12734] When linking projects

that contain `fixed order` blocks with mixed very high (like 1024 and higher) alignments, and

where the block with the highest alignment is not the first block in the `fixed order` sequence, and

where the blocks contain a mix of initialized and zero initialized content, and

where the blocks are placed with the `place at end of` directive,

the linker can terminate with an internal error (`Distributor::TraverseRanges - range overshoot: <addresses>`).

In 9.60.3
[EWARM-12239, TPB-3887] When linking an application, the ILINK linker can fail to include debug information sections in modules that were compiled by non-IAR compilers. If the first mentioned Alloc section was suppressed by the linker, the entire debug section was discarded. (The `A` flag for sections - Alloc sections are downloaded to the target processor, non-Alloc sections are not.) This could affect different debug sections in the same module in different ways. This problem was introduced in IAR Embedded Workbench for Arm 8.30.1.

[EWARM-12196, TPB-3857] When linking content that is read-only and has the ELF property `NOBITS`, the linker generates map files where such content is incorrectly classified. In the Placement summary chapter, such content is listed as `zero` instead of `const`; in the Module summary chapter, such content contributes to `rw data` instead of `ro data`; and in the final linker summary (map file and terminal output), the `readonly` sum is too low and the `readwrite` sum is too high. The issue is only in the map file, the content in the ELF file is correct.
Note: `NOBITS` content is content with no representation in the file because all bytes in the section have the value 0. `const int arr[2000];` is one way to get such a section.

[EWARM-12175, TPB-3854] When generating exception unwind information (using the `--exception_tables=unwind` option), the linker can terminate with an internal error if any object file for which unwind information was generated contains an `.iar.noinitinfo` section (typically generated by use of the IAR extended keyword `__no_init`).

[EWARM-12053, TPB-3848] When linking projects that use the `--image_input` option, the linker can spuriously treat symbols defined in the linker configuration file as fragment start symbols. This triggers an access violation. The problem was introduced in `ilinkarm` 9.50.1 (released 2023-Nov-28).

[EWARM-12004, TPB-3837] Using the `do not initialize` linker directive on a section that is not writable can lead to the linker reporting spurious Lp062 errors (`ROM placement includes sections with no content`). The expected result would have been that this has no effect, non-writable content is not initialized.

[TPB-3865] When calculating checksums for 64-bit ELF files, `ielftool` does not handle the checksum symbol correctly. This typically results in `ielftool` terminating with an access violation message.

New features

None

V9.50 2023-11-28

Program corrections

In EWARM 9.50.2
[EWARM-12165, TPB-3855] In the linker map file, global symbols are listed as having the type ?? instead of the expected Gb. This is a problem in the map file only, it has no impact on the generated ELF file.
In EWARM 9.50.2
[EWARM-12112, TPB-3851] When performing stack usage analysis, the linker can terminate with an internal error if at least one function is missing or has incomplete stack usage information.
In EWARM 9.50.2
[EWARM-12053, TPB-3848] When linking projects that use the --image_input option, the linker can spuriously treat symbols defined in the linker configuration file as fragment start symbols. This triggers an access violation. The problem was introduced in ilinkarm 9.50.1 (released 2023-Nov-28).
[EWARM-11354] When linking object files that were compiled with different DSP settings (like Cortex-M33.no_dsp vs Cortex-M33), the linker fails to report the mismatch if a CPU without a DSP was specified on the linker command line.

New features

None

V9.40 2023-05-24

Program corrections

In EWARM 9.40.2
[EWARM-11554, TPB-3804] When ielftool calculates a checksum where the checksum range contains parts whose address was modified using the logical linker directive, ielftool spuriously uses the virtual address instead of the physical address. (The virtual address is the execution address, where the content resides during execution, and the physical address is the file address, where the content resides before being loaded into memory).
Typically, this results in a "checksum range contains uninitialized data" error (because there are no bytes to process at the virtual address), but in cases where virtual addresses overlap physical addresses, this can result in the wrong bytes being processed. This has always been a problem with the --checksum option.
[EWARM-10901] From the EWARM 9.40 release, ilinkarm now sets the ELF header flags EF_ARM_ABI_FLOAT_SOFT and EF_ARM_ABI_FLOAT_HARD.
Arm 32-bit ELF modules can have different calling conventions:
- soft fp (floating point in general registers)
- hard fp (floating point in dedicated fp registers)
- tool specific
- agnostic
If all linked-in modules use soft fp or are agnostic, ilinkarm now sets the EF_ARM_ABI_FLOAT_SOFT flag in the executable file. If all linked-in modules use hard fp or are agnostic, ilinkarm now sets the EF_ARM_ABI_FLOAT_HARD flag in the executable file. In all other cases (mix of hard and soft, any tool specific or all agnostic), none of the bits are set.
[EWARM-10747, TPB-3727] When linking projects where one region wholly contains multiple contiguous sub-regions (for example: region A starts on 0x0 and ends on 0xFFF, region B starts on 0x10 and ends on 0x1F, region C starts on 0x20 and ends on 0x3F, region D starts on 0x40 and ends on 0x4F), the linker can spuriously generate error Lp011 (section placement failed).
[EWARM-10658, TPB-3721] When ielftool fills a memory range for an application that has been linked with a translation from logical to physical ranges, ielftool checks the virtual address instead of the physical address when it generates the filler bytes. In cases where the fill range and the translated physical address overlap, this results in the same byte having two definitions.

New features

None

V9.32 2022-12-13

Program corrections

[EWARM-10692] When linking applications that contain icf blocks that are empty (0 bytes, typically because no content matched the block's selectors) and have alignment requirements, the linker can fail to emit correct diagnostics when the available range does not contain an address that matches the alignment requirement (for example, alignment 32768 with the range 0x10800-0x17FFF). In these situations, the linker can generate incorrect output (where the block is placed outside its designated range) or terminate with an internal error.
[EWARM-10677] When building for Cortex-R52 and C-RUN, the linker selects the library as_wp8Al.a, which does not exist. The existing library as_wp7l.a should be used instead.
[EWARM-10161, TPB-3659] When generating veneers for code that is initialized by copy, the linker can run out of memory (Internal Error: [CoreUtil/General]: Unexpected windows exception) if compression is used and the code has an alignment that is significantly higher than that of the veneers (256 for the code, 8 for the veneers).
[EWARM-10100, TPB-3654] When a block defined with the fixed order property contains a block with the expanding size property, ILINK does not honor the fixed order property. The block with expanding size can end up being placed at an unexpected position (typically last in the block).
[EWARM-9867, TPB-3630] When performing stack usage analysis, the linker now generates warning Ls027 when it encounters a function inside a recursive nest that calls a function not inside that nest that has a calculated maximum stack usage that exceeds that of the deepest cycle of the recursive nest. The stack usage analysis is currently unable to correctly calculate the stack usage in these cases.

New features

None

V9.30 2022-06-02

Program corrections

[EWARM-9910, TPB-3636] When generating output in the Intel Hex format (--ihex) and using the --offset option, ielftool fails to correctly modify the address in an output row if more than one section contributed bytes to that row.
[EWARM-9894, TPB-3632] The linker can terminate with an internal error when linking projects where:
- compressed initializers are used
- some compressed initializer bytes are located inside a configuration file block while others are not
- both types of initializers are placed in the same range.
(Internal error: [CoreUtil/General]: Access violation (reading from address 0x40)).

[EWARM-9832, TPB-3624]

Specifying module-local C++ functions in stack usage control files does not work.
Example:
In the source file test.o:

        static int foo(int) { ... }

In the stack usage control file:

        max recursion depth "foo(int)" [test.o] : 2;

Results in:

Warning[Ls026]: no module-local function matching "foo(int) [test.o]" found

[EWARM-9816, TPB-3621] When generating filler bytes (the --fill option), ielftool considers segments that both contain bytes and have the W flag (writeable content) set to be only writeable, and generates filler bytes as if the segment did not exist. This can result in an image where some addresses have their content specified twice (once from the segment, once from the filler segment).
[EWARM-9797, TPB-3620] When linking applications where the content is spread over multiple ranges, the linker can terminate with an internal error (Internal Error: [CoreUtil/General]: Stack overflow).
[EWARM-9775, TPB-3616] When generating veneers for functions that reside in blocks with the fixed order property, the linker can fail to take into account bytes lost to alignment. This can result in the veneer target having an incorrect address when analyzing whether a veneer is needed or not. In some veneers (like mode-switching veneers on the Arm processor), this can result in no veneer being generated when one is needed. The end result is error Lp002 (Relocation failed). This problem does not affect the actual generation of veneers, only the analysis of whether one is needed.
[EWARM-9747, TPB-3595] When linking projects where at least two blocks contain both compressed initializers and the end of the block is known to contain zeros (this results in a file where the file size is lesser than the memory size), the linker generates a corrupt ELF file. The value of the phoff (program header offset) and shoff (section header offset) members of the ELF header are incorrect. The corrupt file will not be usable by any ELF reader, including ielftool and C-SPY.
[EWARM-9708] When linking projects where there is not sufficient space to satisfy the requirements (error Lp011, section placement failed), the can linker can generate an internal error ("OutputBlock::Create - unexpected index") after generating the Lp011 error.
[EWARM-9692, TPB-3603] When generating output in any output format except raw-binary, ielftool can erroneously claim that a program uses 64-bit addresses ("The segment that starts on 0x0 and ends on 0xffffffffffffffff contains addresses that are greater than 0xffffffff") if the program contains content that has a size of 0 bytes (this is typically empty sections) and resides on address 0.

New features

The IElfTool.zip is now delivered with a CMake configuration file instead of a Visual Studio project.

V9.20 2021-11-02

Program corrections

In EWARM 9.20.3-FS
In EWARM 9.20.4
[EWARM-9517, TPB-3582] When generating filler bytes (the option --fill), ielftool generates filler bytes for segments that are writeable. As a result, the image contains more than one location with the same address (the original content, and the filler bytes generated for that content). Note: Content is typically either read-only or writeable without actual bytes—content that is writeable and has actual bytes is relatively rare.
[EWARM-9420, TPB-3571] When linking with object files produced by gcc/clang, the linker can behave very erratically. The problem occurs only for object files that use ELF common symbols (SHN_COMMON), have one string table section for both section and symbol names, and do not contain a .bss section.
[EWARM-9315, TPB-3563] When calculating a checksum (with the --checksum option), ielftool can spuriously terminate with the following error if the checksummed range contains an empty (0 bytes) ELF segment:
The checksum range contains uninitialized data.
[EWARM-9181, TPB-3556] When calculating a checksum (with the --checksum option), ielftool can spuriously terminate with the following error if the checksummed range contains an empty (0 bytes) ELF segment:
The checksum range contains uninitialized data.
See also EWARM-9315
[EWARM-9048, TPB-3543] In link jobs involving multiple initialized areas and complex ranges (initialize by copy with complex ranges {...}), the linker can terminate with an access violation error: Internal error: [CoreUtil/General]: Access violation.
[EWARM-9011] When linking applications where all input files are libraries (filename extension .a), the linker terminates with an internal error ("Panic, unknown machine!"). The linker needs at least one object module (filename extension .o) to know which standard library to load. This problem was introduced with IAR Embedded Workbench for Arm v9.10 and the support for 64-bit Arm devices.
[EWARM-8970, TPB-3532] When section placement fails (error Lp011 (section placement failed) or Lp015 (section placement failure)) and the application contains compressed initializers, ILINK can terminate with an internal error ("OutputBlock::Create - unexpected index").
[EWARM-8283, TPB-3472] When running the ELF dumper in Windows with the command line option --source (include source in disassembled code in executables), source files using a UNIX end-of-line convention can cause the dumper to misbehave by producing incorrect source text, or by not being able to read source text from such files.
[EWARM-7993, TPB-3425] When generating fill, using the –-fill option, ielftool spuriously generates filler bytes for addresses where nobits ROM sections reside. All bytes in the nobits ROM sections are assumed to have the value 0. If such sections are filled with ielftool, with this problem the value of the bytes will be whatever was used as the fill value in the fill command.

New features

None

V9.10 2021-02-19

Program corrections

In EWARM 9.10.2
[EWARM-8711, TPB-3511] When linking projects containing compressed initializers and the place at end of directive, the linker can fail to place the specified content last. This can happen if there are several regions (note that the presence of absolute content inside a region effectively splits it into two, before and after the absolute content). The initializer bytes can then be placed after the content that was specified in the place at end of directive.
In EWARM 9.10.2
[EWARM-8645, TPB-3506] When generating output in the Intel hex output format, ielftool can produce a superfluous 04-record (Extended Linear Address Record, it sets the high 16 bits of addresses) under the following circumstances:
1) A section does not contain enough bytes to fill a line in the output file, AND
2) The next section contains exactly enough bytes to fill a line, AND
3) The last byte in that section is the last byte before a page boundary (the low 16 bits of the address is 0xFFFF), AND
4) There are no more bytes to output after that section.
A superfluous 04-record has no real meaning and is ignored by most readers.
In EWARM 9.10.2
[EWARM-8635, TPB-3505] When linking projects where all content could not be successfully placed (error Lp011, section placement failed), the linker can terminate with an internal error (after the error message is output) if compressed initializers are used.
In EWARM 9.10.2
[EWARM-8630, TPB-3504] When linking projects containing copy initialized functions (code in RAM) that use veneers, the linker can generate initializer bytes (the ROM bytes that are used to initialize RAM) that have an incorrect size if there are multiple veneers and --no_literal_pool is used. This typically results in error Lp020 (initializers for "section" too large to fit).
In EWARM 9.10.2
[EWARM-8568, TPB-3491] Some sections are not taken into account when unmatched section patterns are listed in the linker map file. This means that patterns that match these sections are incorrectly being listed as unmatched, even if they are in fact matched. Sections affected by the problem include some sections involved in variable initialization, variable initializer sections, and sections for linker-created tables.
In EWARM 9.10.2
[EWARM-8555, TPB-3489] When generating unwind entries (--exception_tables=unwind), the linker fails to correctly process files inside library files. Entries in such files will not have unwind information.
In EWARM 9.10.2
[EWARM-8494, TPB-3486] When generating output in the raw-binary (--bin) output format, ielftool generates unspecified bytes if the file size and memory size for a segment differ (you can find these with ielfdump). If the memory size is 0x40 and the file size is 0x20, the expected behavior is to get 0x20 bytes from the ELF file and the difference (0x40 - 0x20 = 0x20) as zeroes. What actually happens is that the bytes that are supposed to be zeroes are unspecified.
[EWARM-7559, TPB-3335] When generating many (thousands) filler bytes sections, ielftool can require excessive amounts of time (hours) to produce the output file.
[EWARM-7505, TPB-3318] When linking files containing absolutely placed __root __init variables that were declared in a .h file and accessed from more than one module, the linker can fail to correctly suppress one of the definitions. This results in Error Lp025 (absolute section overlaps with absolute section).
[EWARM-7473, TPB-3315] If the application contains dynamically initialized objects and the section .init_array is not matched in any placement directive, ILINK can terminate with an internal error.
[EWARM-7469, TPB-3313] In some cases when the first modifier is used for a section selection pattern in the linker configuration file, the linker can fail to take both first and last modifiers in the containing block or placement into consideration correctly, placing content in the wrong order.
In particular, this can happen when the section selection pattern marked with first matches variable initializers compressed with lz77 or packbits.
[EWARM-7424, TPB-3296] When performing absolute section placement (the place at directive) in situations where there is very little available space, the linker can fail to place content even though the space is actually available. This results in error Lp015 (section placement failure: overcommitted content).
[EWARM-7282, TPB-3264] When calculating checksums using the sum32 algorithm, ielftool uses an initial value of 0, even if a different initial value is specified.
[EWARM-7211, TPB-3258] When using the ielftool option --strip to remove all sections that contain debug information, a file can be produced where section offsets are not a multiple of 4. This has no effect on the application contained in the file, but can result in some readers rejecting the file.
[EWARM-7206, TPB-3256] The fix for TPB 3179 introduced a new problem; if a weak definition is placed at an absolute address and is declared __root it cannot be suppressed by a non-weak symbol placed at the same address. Resolving this issue requires changes in both the compiler and the linker, an updated linker alone is not sufficient.

New features

None.

V8.50 2020-02-17

Program corrections

In EWARM 8.50.9
[EWARM-8188, TPB-3455] When calculating a checksum for a range that contains nobits content (in this particular case the last bytes of a ROM-placed block with a specified size, where the available content does not occupy all available bytes in the block), ielftool can fail to terminate.
In EWARM 8.50.9
[EWARM-8042] When linking for a legacy core (pre-cortex) without FPU, with stack usage analysis enabled, a warning is issued for library symbols __aeabi_f2uiz and __aeabi_f2d:
```
Warning[Ls014]: [stack usage analysis] at least one function does not have stack usage
        information
        
```
The symbols __aeabi_f2uiz and __aeabi_f2d are used to implement conversion of a float value to int or double.
In EWARM 8.50.8
[EWARM-8029, TPB-3430] When linking input files that contain absolute const __no_init content (like __no_init const unsigned short RBT_48 @ 0x1FF0;), the linker spuriously generates segment information for such content. This results in the addresses in question being initialized when the ELF file is loaded. If another output format—like Intel-Hex or Motorola-S-Records—is used, those addresses will be present in the file even though they should not be.
In EWARM 8.50.8
[EWARM-7993, TPB-3425] When generating fill, using the –-fill option, ielftool spuriously generates filler bytes for addresses where nobits ROM sections reside. All bytes in the nobits ROM sections are assumed to have the value 0. If such sections are filled with ielftool, with this problem the value of the bytes will be whatever was used as the fill value in the fill command.
In EWARM 8.50.7
[EWARM-7919, TPB-3413] If a linker placement consists entirely of sections that are not writable (typically ROM content) and nobits (no representation in the file, typically RAM content), the linker fails to generate segment information for those sections.The sections themselves are present in the file, but they will not be present in the list of segments.
In EWARM 8.50.7
[EWARM-7894, TPB-3407] When generating output in the Motorola S-Records, Intel Hex, TI-TXT, Raw Binary, or Simple-code output format, ielftool fails to correctly generate zero bytes (0x00) if a segment's File Sz is different from its Mem Sz.
This can be checked by using ielfdump to inspect the file that ielftool converts. The segments are listed first, and both File Sz and Mem Sz have their own columns in the listing. If File Sz and Mem Sz have the same value, the problem does not arise. However, if they have different values, ielftool will fail to generate zero bytes (0x00). Example: If File Sz is 0x30 and Mem Sz is 0x20, the expected behavior is that the ielftool produces the 0x20 bytes from the file and then 0x10 bytes of zeros (0x00). What ielftool actually produces is just the 0x20 bytes from the file.
In EWARM 8.50.7
[EWARM-7876, TPB-3404] When linking files where one ROM placement is followed by a ROM block with a fixed size and with a higher alignment than the preceding placement, ILINK can fail to correctly account for the space lost to alignment in the segment information (the column called File Sz in ielfdump).
Example:
If the first placement has alignment 4 and a size of 0x1234 bytes, and the block that follows has an alignment of 32 and a fixed size of 0x2000 bytes but only had ROM content for 0x234 bytes, the segment information produced by ILINK claims that File Sz is 0x1234 + 0x234 = 0x1468 bytes. This fails to account for the alignment of the fixed size block. 0xC bytes is needed, so the correct File Sz is 0x1474.
[EWARM-7422, TPB-3294] When iobjmanip removes sections from an ELF file (typically using the --strip or --remove_section option), the numbering of the sections changes, which can corrupt the information in the .iar.noinitinfo section. This can result in incorrect initialization behavior for the file’s content when it is linked with ILINK. See IAR Technical Note 200128 for more information.
[EWARM-7381, TPB-3284] When iobjmanip processes ELF files that contain nobits sections, iobjmanip creates a superfluous, empty .iar.noinitinfo section in the output file. (ELF sections can be nobits or pbits. nobits sections hold content with no bits in the object file, and are zero-initialized or uninitialized.) In most cases, this is not significant, but it can cause problems with some versions of ILINK and iarchive that expect a file to have at most one .iar.noinitinfo section.
[EWARM-7366, TPB-3280] When linking a project where multiple place at directives partition the available space into relatively small ranges, the linker can produce a corrupt output file. The file header contains the file offset of structurally important information, and because that offset is incorrectly generated, the result is a corrupt file that will be rejected by ELF-readers.
[EWARM-7162, TPB-3248] The linker can fail to generate the needed veneers if code is placed in memory ranges such that the distance between the ranges is very near to the maximum distance that can be reached without a veneer (0x100'0000 bytes for thumb2 calls). This generates misleading relocation failed (Lp002) errors for call instructions.

New features

None.

V8.42 2020-01-17

Program corrections

[EWARM-7259, TPB-3260] For several years, the compiler and linker have supported a mechanism by which all __no_init variables are excluded from zeroing. No do not initialize directive is needed. For this reason, the do not initialize { section .noinit }; directive was removed from many of the linker configuration files supplied with the product. However, this change was not backward compatible with code that places variables in the .noinit section instead of using the __no_init keyword. To solve this problem, the linker will in the future behave as if the directive as shown above is present if no other do not initialize directive is found in the linker configuration file.
[EWARM-7182, TPB-3252] The linker can terminate with an internal error if the option --no_library_search is specified, the linker configuration file contains the directive initialize by copy, and the source code contains a definition of __iar_data_init3. If you do not use the IAR runtime library, use initialize manually instead.
[EWARM-7156, TPB-3246] If you use the names of C++ inline functions in stack usage control files, ILINK ignores the stack usage information supplied about those functions.
[EWARM-7127, TPB-3237] When linking a project that has been configured to support RWPI (read-write position-independence), the linker can generate error Lt043 (Base relative relocation to non-static base address) also when the accessed symbol was defined relative to a static base.
[EWARM-7035, TPB-3215] When linking files using a configuration file, where the range of a place in directive is split in two by a place at directive, the linker can, in some cases, fail to allocate sufficient space to a placement request even though such space is available. This will generate error Lp011, and the error text will show an estimated minimum size that is smaller than the uncommitted space.
[EWARM-7033, TPB-3216] When linking a project where the input files do not specify the content of a ROM area in a block (like "define block MYBLOCK with size = 0x20000 { ro };", where the size of the ro content is significantly smaller than 0x20000), the linker can terminate with an internal error ("OutputBlock::Create - wrong owner").
[EWARM-6803, TPB-3146] Ilink can terminate with an internal error ("Int divide by zero") when a configuration block is assigned alignment 0.
[EWARM-6800, TPB-3142] The .iar.noinitinfo section (contains information about which sections should not be initialized) does not survive stripping using --strip in iobjmanip or a third party stripper. If an object file containing .iar.noinitinfo is stripped, the section can cause the wrong section to not be initialized. The format of the section has been updated and it now survives stripping.

New features

None.

V8.40 2019-05-24

Program corrections

In EWARM 8.40.2:
[EWARM-8291, TPB-3469] When performing a stack usage analysis and the input files contain modules that were not compiled with IAR tools (such modules do not contain stack usage information), the linker can terminate with an internal error if the listed symbol size in the ELF file of functions in those modules is 0.
In EWARM 8.40.2:
[EWARM-6962, TPB-3194] When generating output in the Motorola S-records output format and with the --offset option active, the IAR ELF Tool, ielftool, fails to offset rows that are not complete. Other output formats, such as Intel Hex and TI-Txt, do not have this problem. This problem was introduced in the 10.1.5 version of ielftool.
In EWARM 8.40.2:
[EWARM-6898, TPB-3179] When a weak symbol is suppressed, the section that contains the symbol is also suppressed. This has no effect for other symbols in the section if they are referenced (by the application or by the linker option --keep). However, if the other symbols in the section are not referenced, the section will not be included in the output even if the other symbols are meant to be included by use of the keep directive or the linker option -no_remove.
In EWARM 8.40.2:
[EWARM-6893, TPB-3177] If you in section selection in the linker configuration file (.icf) use both the section type init_array or preinit_array and the object selector, no pattern can match the selector. The pattern will be listed in the map file under the heading No sections matched the following patterns. This problem was introduced in version 8.10.

New features

None.

V8.32 2018-10-12

Program corrections

In EWARM 8.32.3 [EWARM-6623, TPB-3078] Some complicated C++ names can cause the demangler to loop. The demangler is used when producing a map file, but also in some other cases (diagnostics, --log call_graph, ...). In all these cases, the linker will loop forever if it encounters one of the problematic names.
In EWARM 8.32.2
[EWARM-6567, TPB-3061] Running on the Windows OS, IElfDumpArm issues an error if the parameter to the command line option --range specifies an address larger than 0x7FFFFFFF.
In EWARM 8.32.2
[EWARM-6523, TPB-3055] When generating the callgraph log file, ilink can fail to terminate if a function name begins with BDCH.
[EWARM-6430, TPB-3044] The linker can terminate with an internal error in some situations involving two or more placements into the same memory range, the first containing a block with partial byte content, and the second containing a block with only space.

New features

None.

V8.30 2018-06-15

Program corrections

[EWARM-6152, TPB-2935] When generating the module summary part of the linker map file, space occupied by placeholder symbols (symbols created through use of the linker option --place_holder) is not listed. This can result in situations where columns in the module summary do not add up to the listed grand total.
[EWARM-6018, TPB-2876] The linker can sometimes fail with error Lp011 ("unable to place sections/blocks...") when placing into more than one address range even when there is plenty of space left. The use of blocks with expanding size makes this problem significantly more likely to occur.
[EWARM-5982, TPB-2861] A subscript expression with a fixed index into a string literal is incorrectly not considered a constant expression in C++ mode. Example: "foo"[0] should be a constant expression with the value 'f'.

New features

None.

V8.22 2018-01-22

Program corrections

None

New features

None

V8.20 2017-10-16

Program corrections

In EWARM 8.20.2
[EWARM-5961, TPB-2855] In some cases involving several place in directives with partially overlapping ranges, the linker can terminate with an internal error ("Distributor::TraverseRanges - range overshoot").
In EWARM 8.20.2
[EWARM-5955, TPB-2853] In some cirumstances involving compressed initializers and partially overlapping placement ranges, the linker can terminate with an internal error.
[EWARM-5828, TPB-2807] The linker can terminate with an internal error when a block without content is placed after compressed initializers.
[EWARM-5811, EW26736] Linking with modules that use C++ dynamic initialization built with gnu tools does not work.
[EWARM-5737, EW26620] In some cases with nested uninited content at the end of ELF segments, the linker is now better at avoiding output of zeros in the executable for the uninited content.

New features

None

V8.11 2017-04-11

Program corrections

In EWARM 8.11.2:
The linker can terminate with an internal error in some cases following a failure to match some sections for section placement (error Lc036).
[EW26530]
In EWARM 8.11.3:
When Ielftool converts output to Motorola S-records or Intel-hex and a line that contains less than 16 payload bytes (a complete line) is followed by an empty (memory size 0) ELF load-segment, the incomplete line is not output and the payload bytes are lost. This problem was introduced in Ielftool 10.1.4.
[TP-768]

New features

None.

V8.10 2017-03-10

Program corrections

The linker can, in rare circumstances, fail to detect placement failure in situations involving compressed initializers being placed in a range that is also used in a place at end directive.
[EW26353]
The linker can fail during section placement ("overcommitted content in ...") even when there is plenty of memory available, in situations involving ranges that are short compared to typical code sections.
[EW26356]
Overlays with existing content in one alternative (ROM overlays) do not work. The existing content is not present in the output file.
[EW26382]
The linker can terminate with an internal error when attempting to place zero-init or copy-init sections in very short ranges (typically 3 bytes or less).
[EW26433]
In some cases involving multiple possible ranges (typically several small ranges and at least one large), where the total memory in the small ranges could be large enough, the linker can fail to place a block or section that is large compared with the small ranges.
[EW26450]

New features

None.

V7.80 2016-10-17

Program corrections

When the reserved space of a checksum symbol in an executable file does not match the corresponding specified checksum size in the --checksum command, ielftool can silently overwrite existing content.
[EW26126]
Stack usage analysis in the linker can end with an internal error after running out of stack when analyzing an application containing tail recursion in more than one step.
[EW26230]

New features

None.

V7.70 2016-06-17

Program corrections

None.

New features

None.

V7.60 2015-03-31

Program corrections

The linker command file stm32f410x.icf has an incorrect definition of the RAM memory area.
[EW25969]
When generating output in the simple and binary output formats, after generating fill in a range containing empty code/const sections, ielftool can generate spurious overlap errors.
[EW25977]
__ALIGNOF__(variable) returns the alignment of the variable's type, not the actual alignment of the variable.
[EW25990]
The default linker configuration file for STM32L151VD-X, stm32l15xVD-X.icf is incorrect.
[EW25973]
In EWARM 7.60.2:
The linker can incorrectly generate (zero) content for __no_init read-only sections not mentioned in a do not initialize directive.
[EW26034]

New features

None.

V7.50 2015-11-10

Program corrections

ielftool has been changed so that using --srec-s3only or --srec-len automatically assumes --srec if no output format has been specified. Also, a warning is emitted for use of --srec-s3only/--srec-len if some other output format has been specified.
[EW25699]
Variables declared both const and __no_init are output as actual zeros by the linker. No content should be generated by the linker for these variables.
[EW25771]
In EWARM 7.50.2
The linker can place content in fixed order blocks in an incorrect order when some of the content is initializer data packed using the packbits or lz77 packing methods. Note that the first and last placement modifiers result in an implicit use of a fixed order block.
[EW25807]
In EWARM 7.50.3:
Ilink can fail to place sections where older versions succeeded, in some rare cases involving sub-ranges smaller than the size of a compressed initializer batch.
[EW25827]

New features

None.

V7.40 2015-02-19

Program corrections

Compiler-generated annotations for stack usage analysis were lost during instruction scheduling for instructions within IT blocks. This could result in faulty stack usage analysis.
[EW25111]
The linker can terminate with an internal error after diagnosing that some absolute variables cannot be runtime-initialized because they do not meet the alignment requirements.
[EW25212]
In EWARM 7.40.2:
When performing stack usage analysis where the maximum call chain includes a recursive call nest for which a max recursion depth has been specified, the stack usage numbers for the functions in the nest can be listed on the wrong function.
[EW25264]
In EWARM 7.40.5:
The diagnostic message produced when not finding a match for a module-local symbol pattern in a stack usage control file does not make clear that the pattern can only match module-local symbols.
[EW25457]
In EWARM 7.40.5:
In some cases where a function tail calls another, the compiler fails to generate stack usage information about this call, leading to stack usage analysis errors in the linker.
[EW25463]
In EWARM 7.40.5:
When using the debug heap, references to __iar_dlmalloc_usable_size are incorrectly redirected to __iar_debug_malloc_usable_size instead of __iar_debug_dlmalloc_usable_size. This typically results in an undefined external error.
[EW25552]
In EWARM 7.40.5:
An expression containing a bit-preserving cast of the result of the __section_begin/__section_end/__segment_begin/__segment_end operators is not considered a constant expression. In (E)C++ this can result in a const variable initialized by such an expression being placed in RAM instead of in ROM.
[EW25605]
In EWARM 7.40.5:
Variables that are both __no_init and const are incorrectly generated in writable (instead of non-writable) ELF sections and counted as readwrite data in linker summaries.
[EW25627]

New features

None.

V7.30 2014-09-24

Program corrections

The r flag (reverse the byte order within each word) of the --checksum option did not work as intended. r should only affect the calculated checksum if more than 1 byte is processed in each iteration (that is, if the W or L flag is set). In all versions containing the r, W and L flags before the 7.30 release, the r flag erroneously reversed the order of the input bytes if the checksum unit size was 1 byte (it is 1 by default, 2 if W is used and 4 if L is used). This resulted in an incorrect checksum (the correct bytes are processed, but in the wrong order). If your verification code calculates a checksum that matches the erroneous checksum calculated by the older versions, your verification code is likely to have the same problem that the old ielftool version had. Note: Using the r flag without the W or L flag is not really meaningful, there is no byte order to reverse when bytes are read one at the time.
[EW25274]
In EWARM 7.30.3:
The linker incorrectly warns about image input files not containing the information to support Virtual Function Elimination.
[EW24962]
In EWARM 7.30.3:
When performing stack usage analysis in the linker for a C++ program using virtual function calls, if Virtual Function Elimination is disabled for any reason, the information about possible virtual function calls is not collected, resulting in false warnings and unnecessarily imprecise stack usage output.
[EW24964]
In EWARM 7.30.3:
In some situations involving placing sections or blocks at the end of a memory range in which other sections or blocks are also placed, the linker can fail to detect when space runs out and silently place the sections or blocks in an overlapping fashion.
[EW24977]
In EWARM 7.30.3:
Section placement in the linker can fail incorrectly in cases involving many fixed size place at directives.
[EW25053]
In EWARM 7.30.4:
The builtin operators __section_begin, __section_end, etc, always return 0 for the linker-created section .iar.init_table.
[EW25073]
In EWARM 7.30.4:
When linking a configuration for loading directly into RAM, the linker can mistakenly merge read/write segments with content (initialized variables) with segments containing zero initialized or uninitialized sections, resulting in unecessarily large binary files and long load times.
[EW25091]
In EWARM 7.30.4:
The linker can terminate with an internal error after one or more normal errors in some cases involving section placement failure and sections placed at addresses dependent on the size of compressed initializers.
[EW25098]

New features

None.

V7.20 2014-05-19

Program corrections

Non-absolute root sections can be incorrectly excluded from a build when symbols defined in them are suppressed as a result of duplicate symbol definition resolution.
[EW24613]
In EWARM 7.20.2:
The last modifier has no effect when placing an overlay (as opposed to a block or section pattern) in a linker placement directive in the linker configuration file.
[EW24712]
In EWARM 7.20.2:
The linker reported a violation of MISRA C:2004 rule 5.1 within the C-RUN libraries, although the rule does not apply to system libraries.
[EW24714]
In EWARM 7.20.2:
The C-RUN debug heap function __iar_leaks_ignore_all() is not properly handled in the linker. Use __iar_debug_leaks_ignore_all() as a workaround.
[EW24728]
In EWARM 7.20.2:
Assembler root sections with one or more suppressed weak symbol definition can sometimes erroneously be dropped when linking.
[EW24757]
In EWARM 7.20.2:
The linker now handles big endian correctly when linking for Cortex-M4.
[EW24799]
In EWARM 7.20.5:
Using an except clause when defining a fixed order block does not have the intended effect.
[EW24785]
In EWARM 7.20.5:
The linker option --no_remove, to suppress unused section removal, interacts poorly with the support for C-RUN, resulting in unwanted inclusion of the global C-RUN bounds table even when not needed.
[EW24797]
In EWARM 7.20.5:
Due to a bug in the compiler, Virtual Function Elimination (--vfe) in the linker can incorrectly discard virtual functions referenced only from pointer to member function constants in the initializers for aggregate objects.
Example:
int (B::*arr[])() = { &B::fun }; [EW24822]
In EWARM 7.20.5:
When using multi-file compilation (--mfc) in (E)C++, the linker emits spurious warnings about missing Virtual Function Elimination information in the extra (empty) object files generated by the compiler.
[EW24844]

New features

None.

V7.10 2014-02-21

Program corrections

The linker now warns about section placement patterns which do not match any sections, if there exist sections with similar names to the one used in the pattern and these sections would otherwise have been a match.
[EW24096]
In some cases involving the packing algorithm lz77, either by default or specifically, where section placement fails, the linker can stop with an internal error after reporting the section placement failure.
[EW24179]
After emitting error Lp011, section placement failed, the linker can terminate with an internal error.
[EW24446]
Sometimes, when a single section placement directive results in more than one content being placed into more than one address range, the linker can create multiple sections in the output file with the same name. If this output file is used with ISymExport --reserve_ranges to produce an input file for another link job, this input file can contain multiple symbol definitions with the same name, causing the later link job to fail.
[EW24456]
In EWARM 7.10.3:
When using --no_remove to keep all sections, absolute symbols with a size (like those produced by ISymExport in many cases) are not included in the output. Furthermore, using --keep has no effect on these symbols in this case.
[EW24528]
In EWARM 7.10.3:
When directed to perform Virtual Function Elimination, the linker should check that all modules contain the necessary information, and disable the optimization with a warning if any file lacks this information. This check is broken, and the linker never emits the warning and always performs the optimization when so directed, potentially resulting in a non-functioning program.
[EW24556]
In EWARM 7.10.3:
Placing an assembler label in Thumb code after the last content in a section can cause an internal error when linking.
[EW24575]

New features

None.

V6.70 2013-10-29

Program corrections

ISymExport now always includes any range reservation symbols resulting from --reserve_ranges and --ram_reserve_ranges, regardless of what is in the steering file.
[EW24132]
The linker assigns incorrect addresses to zero-initialized variables from modules compiled with gcc. The addresses are off by the alignment of each variable, which can lead to partial or complete overlap with whatever is placed after the variables.
[EW24155]
In EWARM 6.70.2:
When there are zero-initialized sections both inside and outside a movable block, an incorrect estimation for the size of the init table causes the linker to loop while creating an increasingly large output file.
[EW24228]
In EWARM 6.70.2:
The library source xwctomb.c can not be compiled with UTF-8 encoding enabled.
[EW24257]
In EWARM 6.70.2:
Linking a module containing multiple consecutive non-zero size relocations for the same location caused the linker to abort with an internal error. IAR Systems tools cannot currently produce such modules.
[EW24271]
In EWARM 6.70.2:
Multiple copies of __root __no_init absolute placed variables could be kept by the linker, leading to spurious overlap errors. The problem is not present when compiling in AEABI mode.
[EW24287]
In EWARM 6.70.2:
Sections or blocks placed with a last or first modifier immediately inside a place in directive with multiple effective address ranges can be incorrectly placed.
[EW24333, EW24391]

New features

None.

V6.60 2013-06-27

Program corrections

ielftool could fail with an incorrect "The checksum range contains uninitialized data" error when directed to perform fill/checksum calculation on an executable file with a zero-sized ROM segment.
[EW23895]
When generating a wide sum8 checksum with mirroring, ielftool only mirrored 8 bits, not the entire checksum.
[EW23921]
The linker can terminate with an internal error when linking a C++ program using exceptions with --no_remove.
[EW24673]
In EWARM 6.60.2:
ielftool does not check for overlapping sections in the input file when producing output in raw binary, which results in a very large output file containing mostly garbage.
[EW24084]

New features

None.

V6.50 2012-11-10

Program corrections

When performing Virtual Function Elimination, the linker could terminate with an internal error if a reference was made to a non-existing virtual function (this can happen if two modules have been compiled using conflicting definitions of a class). This condition is now detected and an error is generated.
[EW23038]
When linking code for ARM generation 4 processors, the possibility of fall-through veneers was not always taken correctly into account when allocating space for code sections. In particular, this could lead to an internal error if such a veneer was generated in code that was initialized by copy (through the use of the __ramfunc attribute, or via linker directives). This has been corrected.
[EW23256]
When performing stack depth analysis, the linker no longer terminates with an internal error when the program references an undefined virtual function.
[EW23299]
In some cases involving compressed initializers, the linker could place sections beyond the end of a placement range without issuing an error message. This has been corrected.
[EW23396]
iobjmanip did not preserve the address property of sections. If iobjmanip was used for removing debug information from an object file with some absolute sections, these sections were all located at address 0 in the output file. This has been corrected.
[EW23490]
The linker sometimes incorrectly calculated the space needed for compressed initializers for code in RAM that could contain veneers, especially fall-through veneers, leading to spurious Lp020 errors (compressed initializers too large to fit). This has been corrected.
[EW23551]
In EWARM 6.50.3:
The linker terminated with an internal error if any copy initialized absolute sections were needed, unless there were other (not copy initialized) absolute sections adjacent. This has been corrected.
[EW23662]
In EWARM 6.50.3:
In some cases involving recursion via a function pointer argument, the linker could crash during stack usage analysis. One case where this could happen was if one of the functions called by the printf implementation (like putchar) could in turn call printf. This has been corrected.
[EW23696]
In EWARM 6.50.3:
There was an error in the function that attempts to place initializer bytes toward the end of sections. The result was that error Lp017 and Lp021 could be emitted in some circumstances when sections should have been placed so as to avoid this. This has been corrected.
[EW23700]
In EWARM 6.50.3:
Link jobs involving zero-sized blocks could incorrectly fail with error Lp011 (section placement failed). This has been corrected.
[EW23721]
In EWARM 6.50.4:
The library routine for unpacking compressed initializers using the lz77 packing method did not work correctly when there were multiple destination ranges. This has been corrected.
[EW23790]
In EWARM 6.50.4:
The handling of timezones that are to the west of UTC (has a negative offset in the __getzone string) did not work for the 64-bit versions of the time functions. This has been corrected.
[EW23792]

New features

None.

V6.40 2012-06-05

Program corrections

The == and != operators in linker configuration files produced incorrect results.
[EW22755]
Using two or more --image_input command line options without a symbol argument resulted in a duplicated symbol definition error for the internal linker-generated mode symbols as these were incorrectly made public in this case.
[EW22781]
Inline functions could incorrectly be considered a violation of MISRA C:2004 rule 8.10 (use statics when possible).
[EW22833]
Unclosed quoted strings in the linker configuration file caused the linker to freeze.
[EW22908]
In rare circumstances for C++ code with exceptions, the linker could emit an internal error instead of a regular error when section placement failed.
[EW23044]
Ending the line after an ISymExport steering file directive with a C-style comment caused a parse error.
[EW23079]
Using the possible calls stack usage control directive for a function performing only indirect calls via function pointers passed as arguments had no effect.
[EW23107]
The linker could crash during stack usage analysis if the program contained a function call with a constant function pointer argument for a function that could call the calling function.
[EW23127]
The packbits unpacker did not work correctly when there were multiple source or destination ranges.
[EW23134]
For some targets, the zero-init routine, and some copy-init routines, have alignment requirements on the areas they can initialize. In these cases the linker often did not correctly check that variables explicitly located at an absolute address could be initialized by the relevant routines, leading to a variety of internal errors when linking. There should now be an error for each case that is not supported.
[EW23180]
The linker now warns if the content in a place at directive is not placed at the designated address because of alignment issues.
[EW23215]

New features

None.

V6.30 2011-10-22

Program corrections

Assembler files with incorrect mode annotations - DATA, CODE16, etc - no longer causes an internal error in the linker.
[EW22464]
Using the place at end linker directive with a block that has an alignment larger than its size no longer results in an internal error.
[EW22620]
In EWARM 6.30.3:
The linker will no longer inline symbols used by the debugger: __iar_semihosting, __iar_return_from_swi, __iar_sh_stdout_swo.
[EW22789]
In EWARM 6.30.3:
Linking a project with overlapping absolute sections (for instance from different SFRs at the same address), no longer results in one or more spurious error Lp015 (committed sections too large to fit) messages.
[EW22798]
In EWARM 6.30.3:
The heap in use is now the advanced version, dlmalloc, provided that the application refers to the heap (not counting references from library functions) and that the option --basic_heap is not used.
[EW22800]
In EWARM 6.30.3:
Absolute sections (and the symbols defined in them) could be assigned incorrect addresses by the linker. In the typical case, this would not affect the code, as references from code typically use the address directly, but it would affect the map file and the debugger. This problem has been corrected.
[EW22836]
In EWARM 6.30.3:
Providing stack usage information in a stack usage control file for a function that is present when linking, but not included in the final program, no longer causes a crash.
[EW22846]
In EWARM 6.30.5:
Using the override keyword in a stack usage control file to override the stack usage information provided in an object file no longer causes an internal error in the linker.
[EW22874]
In EWARM 6.30.5:
Incorrect region calculations involving ranges wrapping around address zero could lead to spurious emission of error Lp022 (absolute placement overlaps with previous absolute placement) and other problems. This has been corrected.
[EW22941]

New features

None.

V6.21 2011-07-05

Program corrections

None.

New features

None.

V6.20 2011-04-29

Program corrections

Using the place at end of directive with content that includes a high-alignment section or block no longer causes an internal error.
[EW22255]
Using --strip with ielftool did not remove all debug info related ELF sections, such as string tables. Now these are also removed.
[EW22372]

New features

None.

V6.10 2010-11-04

Program corrections

The linker could crash with an internal error after issuing error Lp017 (compressed initializers needed an address that could not be determined until the size of compressed initializers is known).
[EW21191]
In some circumstances a place at directive with no needed content and a memory range partially overlapping other section placement directives could cause an internal error.
[EW21572]
If the sections/blocks in place at directives did not fit in the specified ranges, the diagnostic message produced was nonsensical. Example:
Error[Lp011]: section placement failed: unable to allocate space for sections/blocks with a total estimated minimum size of 0x0 bytes in <> (total uncommitted space 0xffffffffffff372c). Needed:
[EW21849]
C-SPY could emit a spurious "ROM size limit exceeded" error when loading Release build output from a product with a ROM size limit where some ROM usage is not counted against the limit.
[EW21909]
ielftool now uses segment data instead of section data when executing the fill and checksum functions.
[EW22329]
Iarchive now returns a proper exit status when using the silent option.
[EW21944]

New features

None.

V5.50 2010-04-21

Program corrections

Needed module-local absolute symbols were not kept by the linker, and no space was reserved for them.
Example:
static __no_init int array[10] @ 0x100;
[EW21528]
Section placement could fail when several place at commands were used in such a fashion that overlap could occur if veneers were needed.
[EW21647]
Expanding an ELF section that did not end on an even 4-byte boundary could lead to an error.
[EW21654]
In EWARM 5.50.5:
A sequence of place at section placement directives into the same memory region, where one contained compressed initializers, and a later one consisted only of blocks with no content, no longer results in an internal error in the linker.
[EW21746]
In EWARM 5.50.5:
Starting with ilinkarm 5.50.0, the linker always generated an init table section. In builds where an init table is not needed, this unnecessarily required the configuration file to contain a section placement pattern that matched the init table section. The init table section is no longer generated when it is not needed.
[EW21761]

New features

None.

V5.41 2009-12-14

Program corrections

Linking no longer fails with error Lp020 (compressed initializers too large to fit) in cases involving initialization by copy of a block of code needing veneers, where some of the code sections had a smaller alignment than the veneers.
[EW21183]
In EWARM 5.41.2:
A place in directive in a range straddling the start/end of the range of a place at directive no longer causes the linker to terminate with an internal error.
[EW21488]
In EWARM 5.41.2:
In assembly code, pc-relative instructions (like branches) referring to an absolute address no longer incorrectly results in undefined symbol errors when linking.
[EW21525]

New features

None.

V5.40 2009-07-10

Program corrections

Section placement could fail with an internal error [range allocation inconsistency] when the needed range for a place at command partially overlapped a place in command with a larger start address.
[EW20817]
When using compressed initializers with the compression algorithms packbits, lzw, or bwt, the linker cannot handle placing the destination of the initializers at an address that is dependent on the size of the initializers. Doing this resulted in an internal error but now instead results in the new error Lp021.
[EW20842]
Including the locale.h file would force linkage with the full DLIB (including locale support). This has been corrected to only occur if locale support is actually requested.
[EW20850]
ielftool no longer crashes when using an ELF file without a symbol table as input.
[EW20883]
In some circumstances place at directives could cause linking to fail with error Lp011 (section placement failed).
[EW20901]
When building initialization tables in link jobs with multiple zero or copy areas not inside blocks, an internal calculation error in the linker could cause section placement to fail with error Lp011.
[EW20968, 20986]
The compiler emits debug information for an enumeration type if any of its constants are used, even if the type itself is not used. For unnamed enumeration types these constants were not visible in the debugger. Now they are.
[EW21053]
Placing the linker-generated init table using an 'at end' placement could result in an internal error in the linker.
[EW21065]
In EWARM 5.40.4:
The linker has been changed to assume that the automatically chosen libraries are consistent with the command line options.
[EW21201]
In EWARM 5.40.4:
ielftool now generates correct output when the input ELF file contains a segment with more than one section.
[EW21194,EW21196,EW21286]

New features

None.

V5.30 2009-01-23

Program corrections

In EWARM 5.30.2:
Linking an application with compressed initializers inside a block whose end was referenced (using __section_end or a $$Limit symbol) caused an array bounds violation in Ilink, which could result in an internal error or worse.
[EW20796]
Linking an object file with a section consisting entirely of zero-size fragments caused an internal error in the linker.
[EW19873]
When linking files where a placement was empty but had an alignment requirement, The linker could terminate with an internal error (ApplyState - No allocation change).
[EW20353]
Section placement could earlier fail for very small sections in some cases. Typically, this could happen when functions and variables were placed in the same memory area, and there were many calls that were close to the limit of their reach. This caused great uncertainty about how many veneers that were needed.
[EW20464]
After emitting the appropriate error message, the linker could terminate with an internal error if some sections in the program did not match any placement directive.
[EW20481]
The linker could earlier terminate with an internal error if the configuration included a place in directive and a place at directive with the same start address, and the contents of the place at directive occupied zero bytes.
[EW20656]
Compatibility checking for functions in translation units compiled without --interwork and containing a mixture of static and public functions was earlier broken in the linker, which could result in spurious compatibility errors (Lt020) as well as a failure to report such problems when they should be reported.
[EW20745]

New features

Compressed initializers
The linker can compress initialized data to minimize flash use. The compressed data will be atomatically uncompressed when moved from flash to RAM by the startup code.

V5.20 2008-06-24

Program corrections

Using the export directive to export an unknown symbol from a linker configuration file no longer causes ilinkarm to terminate with an internal error after reporting the problem.
[EW19729]
ielftool can now calculate a sum32 checksum on ELF sections that have a length that is not a multiple of 4.
[EW19817]
ielftool can now perform a fill operation on ELF files that contain sections with a length that is not a multiple of 4.
[EW19835]
ilinkarm no longer fails to emit some zeroing init table entries, that caused program startup to fail to fill with zeros one or more memory ranges that should be filled with zeros.
[EW19853]
When checking MISRA C rule 23, ilinkarm no longer erroneously includes some tool internal symbols, which could result in unwanted rule violation errors.
ilinkarm also no longer crashes if error Li0005 (undefined symbol) has occurred previously.
[EW19897]
A place at directive that matches no sections and contains no blocks and which overlaps the memory region of a place in directive, no longer causes an internal error when linking.
[EW19952]
[EW20030]
When linking a project that contains overlapping ranges, ilinkarm no longer terminates with an internal error if the size of the overlap is small compared to the size of the ranges.
[EW19985]
Intel hex output from ielftool no longer contains incorrect base address records if the source ELF file contains no data before sections that start on a new base address.
[EW20031]
Copy initialization of code in a block is no longer generated incorrectly if the first thing in the block is a veneer.
[EW20040]
Chained if directives (if...else if...else) in linker configuration files now work correctly.
[EW20104]
The linker no longer gets an internal error (range allocation inconsistency) when a place at and a place in section placement directive use the same start address.
[EW20183]

New features

Copy code to RAM
Improved features for copying all of the code to RAM at program startup. See above.
Position-independent veneers
The linker can generate position-independent veeners using the --pi_veneers command line option.

V5.11 2007-12-11

ilinkarm could erroneously place fall-through veneers at the start of a place at linker directive, displacing the section that was intended to end up there.
[EW19456]
ielftool (earlier ichecksum) now handles checksums for big-endian files correctly.
[EW19466]
ielftool (earlier ichecksum) did not recognize the arithmetic sum algorithm.
[EW19490]
In some cases, ielftool (earlier ichecksum) did not write the checksum value to the output file.
[EW19496]
The linker erroneously included multiple definitions for the same symbol when input contained a mix of weak definitions for the same symbol, where some of the definitions used an ELF section group, and some of the definitions did not.
[EW19502]
ielftool (earlier ichecksum) now prints an error message when the checksum placeholder variable is not defined as const.
[EW19538]
Using place at into the middle of a place in range could earlier trigger an internal error.
[EW19578]
ilinkarm sometimes reserved an extra, unneeded, byte for 'place at' placements.
[EW19604]
In some cases the linker could place a fall-through mode-changing veneer somewhere other than immediately preceding the destination of the veneer, resulting in non-working code.
[EW19726]

V5.10 2007-05-25

First release.