4.2 List of the armlink error and warning messages

A list of the error and warning messages that armlink produces.

Note:

License-related error messages can be found in the 2.1 List of the licensing error and warning messages section.
L6000U: Out of memory.

This error is reported by RVCT v4.0 and earlier. For more details on why you might see this error and possible solutions, see the description for error L6815U.

L6001U: Could not read from file <filename>.
L6002U: Could not open file <filename>: <reason>

This indicates that the linker was unable to open a file specified on the linker command line. This can indicate a problem accessing the file or a fault with the command line. Some common examples of this message are:

  • L6002U: Could not open file /armlib/{libname}: No such file or directory
    

    Either specify the library path with --libpath or set the ARMCC5LIB environment variable to install_directory\lib.

    Note:

    In ARM Compiler v5.0 and later, armlink does not require the ARMCC5LIB environment variable to be set.
  • Error : armlink : L6002: Could not open file errors=ver.txt
    

    This is caused by a missing double-dash (--) in front of errors=ver.txt. If you do not prefix options with -- or -, the linker treats them as input files and fails the link step because it is unable to load all the specified files.

See the following in the armlink User Guide:

--libpath=pathlist.

See the following in the Getting Started Guide:

Toolchain environment variables.

L6003U: Could not write to file <filename>.

An file I/O error occurred while reading, opening, or writing to the specified file.

L6004U: Incomplete library member list <list> for <library>.

This can occur if there is whitespace in the list of library objects.

The following example fails with Fatal error: L6004U: Missing library member in member list for x.lib:

armlink x.lib(foo.o, bar.o)

The following example succeeds:

armlink x.lib(foo.o,bar.o)

Another less common cause is a corrupt library, or possibly a library in an unsupported format.

L6005U: Extra characters on end of member list for <library>.
L6006U: Overalignment value not specified with OVERALIGN attribute for execution region <regionname>.

See the following in the armlink User Guide:

L6007U: Could not recognize the format of file <filename>.

The linker can recognize object files in ELF format and library files in AR format. The specified file is either corrupt, or is in a file format that the linker cannot recognize.

L6008U: Could not recognize the format of member <mem> from <lib>.

The linker can recognize library member objects in the ELF file format. The specified library member is either corrupt, or is in a file format that the linker cannot recognize.

L6009U: File <filename> : Endianness mismatch.

The endianness of the specified file or object did not match the endianness of the other input files. The linker can handle input of either big endian or little endian objects in a single link step, but not a mixed input of some big and some little endian objects.

L6010U: Could not reopen stderr to file <filename>: <reason>

An file I/O error occurred while reading, opening, or writing to the specified file.

L6011U: Invalid integer constant : <number>.

Specifying an illegal integer constant causes this. An integer can be entered in hexadecimal format by prefixing &, 0x, or 0X.

L6015U: Could not find any input files to link.

The linker must be provided with at least one object file to link.

For example, if you try to link with:

armlink lib.a -o foo.axf

the linker reports this error.

You must instead use, for example:

armlink foo_1.o foo_2.o lib.a -o foo.axf
L6016U: Symbol table missing/corrupt in object/library <object>.

This can occur when linking with libraries built with the GNU tools. This is because GNU ar can generate incompatible information.

The workaround is to replace ar with armar and use the same command-line arguments. Alternatively, the error is recoverable by using armar -s to rebuild the symbol table.

L6017U: Library <library> symbol table contains an invalid entry, no member at offset 0x<offset>.

The library might be corrupted. Try rebuilding it.

L6018U: <filename> is not a valid ELF file.
L6019U: <filename> is not a valid 64 bit ELF file.
L6020U: <filename> is not a valid 32 bit ELF file.
L6022U: Object <objname> has multiple <table>.

The object file is faulty or corrupted. This might indicate a compiler fault. Contact your supplier.

L6024U: Library <library> contains an invalid member name.

The file specified is not a valid library file, is faulty or corrupted. Try rebuilding it.

L6025U: Cannot extract members from a non-library file <library>.

The file specified is not a valid library file, is faulty or corrupted. Try rebuilding it.

L6026U: ELF file <filename> has neither little or big endian encoding

The ELF file is invalid. Try rebuilding it.

L6027U: Relocation #<rel_class>:<rel_number> in <objname>(<secname>) has invalid/unknown type.

This might indicate a compiler fault. Contact your supplier.

L6028U: Relocation #<rel_class>:<rel_number> in <objname>(<secname>) has invalid offset.

This might indicate a compiler fault. Contact your supplier.

L6029U: Relocation #<rel_class>:<rel_number> in <objname>(<secname>) is wrt invalid/missing symbol.

The relocation is with respect to a symbol that is either:

  • invalid or missing from the object symbol table

  • a symbol that is not suited to be used by a relocation.

This might indicate a compiler fault. Contact your supplier.

L6030U: Overalignment <overalignment> for region <regname> must be at least 4 and a power of 2

See the following in the armlink User Guide:

L6031U: Could not open scatter description file <filename>: <reason>

An I/O error occurred while trying to open the specified file. This could be because of an invalid filename.

L6032U: Invalid <text> <value> (maximum <max_value>) found in <object>
L6033U: Symbol <symbolname> in <objname> is defined relative to an invalid section.
L6034U: Symbol <symbolname> in <objname> has invalid value.

This is most often caused by a section-relative symbol having a value that exceeds the section boundaries.

L6035U: Relocation #<rel_class>:<rel_number> in ZI Section <objname>(<secname>) has invalid type.

ZI Sections cannot have relocations other than of type R_ARM_NONE.

L6036U: Could not close file <filename>: <reason>

An I/O error occurred while closing the specified file.

L6037U: '<arg>' is not a valid argument for option '<option>'.

The argument is not valid for this option. This could be because of a spelling error, or because of the use of an unsupported abbreviation of an argument.

L6038U: Could not create a temporary file to write updated SYMDEFS.

An I/O error occurred while creating the temporary file required for storing the SYMDEFS output.

L6039W: Relocation from #<rel_class>:<rel_number> in <objname>(<secname>) with respect to <symname>. Skipping creation of R-type relocation. No corresponding R-type relocation exists for type <rel_type>.

--reloc is used with objects containing relocations that do not have a corresponding R-type relocation.

L6041U: An internal error has occurred (<clue>).

Contact your supplier.

L6042U: Relocation #<rel_class>:<rel_number> in <objname>(<secname>) is wrt a mapping symbol(#<idx>, Last Map Symbol = #<last>).

Relocations with respect to mapping symbols are not permitted. This might indicate a compiler fault. Contact your supplier.

L6043U: Relocation #<rel_class>:<rel_number> in <objname>(<secname>) is with respect to an out of range symbol(#<val>, Range = 1-<max>).

Relocations can only be made wrt symbols in the range (1-n), where n is the number of symbols.

L6047U: The size of this image (<actual_size> bytes) exceeds the maximum allowed for this version of the linker
L6048U: The linker is unable to continue the link step (<id>). This version of the linker will not create this image.
L6049U: The linker is unable to continue the link step (<id>). This version of the linker will not link with one or more given libraries.
L6050U: The code size of this image (<actual_size> bytes) exceeds the maximum allowed for this version of the linker.
L6058E: Syntax error parsing linker script <script> at line <lineno> : <token>

The link ld script has a syntax error at the line number.

See the following in the armlink User Guide:

GNU ld script support in armlink.

L6064E: ELF Executable file <filename> given as input on command line

This might be because you specified an object file as output from from the compiler without specifying the -c compiler option. For example:

armcc file.c -o file.o

armlink file.o -o file.axf

See the following in the armcc User Guide:

-c.

L6065E: Load region <name> (size <size>) is larger than maximum writable contiguous block size of 0x80000000.

The linker attempted to write a segment larger than 2GB. The size of a segment is limited to 2GB.

L6175E: EMPTY region <regname> cannot have any section selectors.
L6176E: A negative max_size cannot be used for region <regname> without the EMPTY attribute.

Only regions with the EMPTY attribute are permitted to have a negative max_size.

L6177E: A negative max_size cannot be used for region <regname> which uses the +offset form of base address.

Regions using the +offset form of base address are not permitted to have a negative max-size.

L6188E: Special section <sec1> multiply defined by <obj1> and <obj2>.

A special section is one that can only be used once, such as "Veneer$$Code".

L6195E: Cannot specify both '<attr1>' and '<attr2>' for region <regname>

See the following in the armlink User Guide:

L6200E: Symbol <symbolname> multiply defined by <object1> and <object2>.

A common example of this:

Symbol __stdout multiply defined (by retarget.o and stdio.o).

This means that there are two conflicting definitions of __stdout present in retarget.o and stdio.o. The one in retarget.o is your own definition. The one in stdio.o is the default implementation, which was probably linked-in inadvertently.

stdio.o contains a number of symbol definitions and implementations of file functions like fopen, fclose, and fflush.

stdio.o is being linked-in because it satisfies some unresolved references.

To identify why stdio.o is being linked-in, you must use the --verbose link option switch. For example:

armlink [... your normal options...] --verbose --list err.txt

Then study err.txt to see exactly what the linker is linking in, from where, and why.

You might have to either:

  • eliminate the calls like fopen, fclose, and fflush

  • re-implement the _sys_xxxx family of functions.

See the following in the ARM C and C++ Libraries and Floating-Point Support User Guide:

Tailoring input/output functions in the C and C++ libraries.

L6201E: Object <objname> contains multiple entry sections.

The input object specifies more than one entry point. Use the --entry command-line option to select the entry point to use.

See the following in the armlink User Guide:

--entry=location.

L6202E: <objname>(<secname>) cannot be assigned to non-root region '<regionname>'

A root region is a region that has an execution address the same as its load address. The region does not therefore require moving or copying by the scatter-load initialization code.

Certain sections must be placed in a root region in the image, including:

  • __main.o.

  • The linker-generated table (Region$$Table).

  • Scatter-loading (__scatter*.o) objects from the library.

  • Decompressor (__dc*.o) objects from the library.

If a required section is not placed in a root region, the linker reports, for example:

anon$$obj.o(Region$$Table) cannot be assigned to a non-root region 'RAM'.

You can use InRoot$$Sections to include all required sections in a root region:

ROM_LOAD 0x0000 0x4000
{
  ROM_EXEC 0x0000 0x4000 ; root region
  {
    vectors.o (Vect, +FIRST) ; Vector table
    * (InRoot$$Sections) ; All library sections
                         ; that must be in a root region
                         ; for example, __main.o, __scatter*.o,
                         ; dc*.o and * Region$$Table
  }
  RAM 0x10000 0x8000
  {
    * (+RO, +RW, +ZI) ; all other sections
  }
}
L6203E: Entry point (<address>) lies within non-root region <regionname>.

The image entry point must correspond to a valid instruction in a root-region of the image.

L6204E: Entry point (<address>) does not point to an instruction.

The image entry point you specified with the --entry command-line option must correspond to a valid instruction in the root-region of the image.

See the following in the armlink User Guide:

--entry=location.

L6205E: Entry point (<address>) must be word aligned for ARM instructions.

This message is displayed because the image entry point you specified with the --entry command-line option is not word-aligned. For example, you specified --entry=0x8001 instead of --entry=0x8000.

See the following in the armlink User Guide:

--entry=location.

L6206E: Entry point (<address>) lies outside the image.

The image entry point you specified with the --entry command-line option is outside the image. For example, you might have specified an entry address of 0x80000 instead of 0x8000, as follows:

armlink --entry=0x80000 test.o -o test.axf

See the following in the armlink User Guide:

--entry=location.

L6208E: Invalid argument for --entry command: '<arg>'

See the following in the armlink User Guide:

--entry=location.

L6209E: Invalid offset constant specified for --entry (<arg>)

See the following in the armlink User Guide:

--entry=location.

L6210E: Image cannot have multiple entry points. (<address1>,<address2>)

One or more input objects specifies more than one entry point for the image. Use the --entry command-line option to select the entry point to use.

See the following in the armlink User Guide:

--entry=location.

L6211E: Ambiguous section selection. Object <objname> contains more than one section.

This can occur when using the linker option --keep on an assembler object that contains more than one AREA. The linker must know which AREA you want to keep.

To solve this, use more than one --keep option to specify the names of the AREAs to keep, such as:

 --keep boot.o(vectors) --keep boot.o(resethandler) …

Note:

Using assembler files with more than one AREA might give other problems elsewhere, so this is best avoided.

L6213E: Multiple First section <object2>(<section2>) not allowed. <object1>(<section1>) already exists.

Only one FIRST section is permitted.

L6214E: Multiple Last section <object2>(<section2>) not allowed. <object1>(<section1>) already exists.

Only one LAST section is permitted.

L6215E: Ambiguous symbol selection for --First/--Last. Symbol <symbol> has more than one definition.

See the following in the armlink User Guide:

L6216E: Cannot use base/limit symbols for non-contiguous section <secname>

The exception handling index tables generated by the compiler are given the section name .ARM.exidx. For more information, see Exception Handling ABI for the ARM Architecture.

At link time these tables must be placed in the same execution region and be contiguous. If you explicitly place these sections non-contiguously using specific selector patterns in your scatter file, then this error message is likely to occur. For example:

LOAD_ROM 0x00000000
{
  ER1 0x00000000
  {
    file1.o (+RO) ; from a C++ source
    * (+RO)
  }
  ER2 0x01000000
  {
    file2.o (+RO) ; from a C++ source
  }
  ER3 +0
  {
    * (+RW, +ZI)
  }
}

This might produce the following error if exception handling index tables are in both file1.o and file2.o, because the linker cannot place them in separate regions:

Error: L6216E: Cannot use base/limit symbols for non-contiguous section .ARM.exidx

Also, the .init_array sections must be placed contiguously within the same region for their base and limit symbols to be accessible.

The correct code is:

LOAD_ROM 0x00000000
{
  ER1 0x00000000
  {
    file1.o (+RO)   ; from a C++ source
    * (.ARM.exidx)  ; Section .ARM.exidx must be placed
                    ; explicitly, otherwise it is shared between
                    ; two regions and the linker is unable to
                    ; decide where to place it.
    *(.init_array)  ; Section .init_array must be placed
                    ; explicitly, otherwise it is shared between
                    ; two regions and the linker is unable to
                    ; decide where to place it.
    * (+RO)
  }
  ER2 0x01000000
  {
    file2.o (+RO)   ; from a C++ source
  }
  ER3 +0
  {
    * (+RW, +ZI)
  }
}

In this example, the base and limit symbols are contained in .init_array in a single region.

See the following in the ARM C and C++ Libraries and Floating-Point Support User Guide:

C++ initialization, construction and destruction.

L6217E: Relocation #<rel_class>:<rel_number> in <objname>(<secname>) with respect to <symbol>. R_ARM_SBREL32 relocation to imported symbol
L6218E: Undefined symbol <symbol> (referred from <objname>).

Some common examples of this are:

  • User Error. There is a reference to an undefined or incorrectly defined symbol.

  • Undefined symbol __ARM_switch8 or __ARM_ll_<xxxx> functions 
    

    The helper functions are automatically generated into the object file by the compiler.

    Note:

    An undefined reference error can, however, still be generated if linking objects from legacy projects where the helper functions are in the h_xxx libraries (h indicates that these are compiler helper libraries, rather than standard C library code).

    Re-compile the object or ensure that these libraries can be found by the linker.

  • When attempting to refer to a function or entity in C from a function or entity in C++. This is caused by C++ name mangling, and can be avoided by marking C functions extern "C".

  • Undefined symbol thunk{v:0,-44} to Foo_i::~Foo_i() (referred from Bar_i.o)
    

    The symbol thunk{v:0,-44} to Foo_i::~Foo_i() is a wrapper function round the regular Foo_i::~Foo_i().

    Foo_i is a derived class of some other base class, therefore:

    • it has a base-class vtable for when it is referred to by a pointer to that base class
    • the base-class vtable has an entry for the thunk
    • the destructor thunk is output when the actual (derived class) destructor is output.

    Therefore, to avoid the error, ensure this destructor is defined.

  • Undefined symbol main (referred from kernel.o)
    

    The linker is reporting that your application does not include a main() function.

See the following in the Migration and Compatibility Guide:

C and C++ library changes between RVCT v2.2 and RVCT v3.0.

L6219E: <type> section <object1>(<section1>) attributes {<attributes>} incompatible with neighboring section <object2>(<section2>).

This error occurs when the default ordering rules used by the linker (RO followed by RW followed by ZI) are violated. This typically happens when one uses +FIRST or +LAST, for example in a scatter file, attempting to force RW before RO.

L6220E: <type> region <regionname> size (<size> bytes) exceeds limit (<limit> bytes).

Example:

Execution region ROM_EXEC size (4208184 bytes) exceeds limit (4194304 bytes).

This can occur where a region has been given an (optional) maximum length in the scatter file, but the size of the code and data being placed in that region has exceeded the limit. This error is suppressible with --diag_suppress 6220.

For example, this might occur when using .ANYnum selectors with the ALIGN directive in a scatter file to force the linker to insert padding. You might be able to fix this using the --any_contingency option.

See the following in the armlink User Guide:

L6221E: <type1> region <regionname1> with <addrtype1> range [<base1>,<limit1>) overlaps with <type2> region <regionname2> with <addrtype2> range [<base2>,<limit2>).

This error can occur even though information in the scatter-loading description file and map information generated by the linker indicate that the execution regions do not overlap.

In RVCT v4.0 and earlier, the linker did not provide as much information, making the message harder to understand:

Warning L6221E: <type1> region <regionname1> overlaps with <type1> region <regionname2>

Example test.s file:

    AREA area1, CODE
    BX lr

    AREA area2, READWRITE, NOINIT
    SPACE 10

    AREA area3, READWRITE
    DCD 10
    END

Example scatter.txt file:

LR1 0x8000
{
  ER1 +0
  {
    *(+ro)
  }
  ER2 +0
  {
    *(+zi)
  }
  ER3 +0
  {
    *(+rw)
  }
}

Built with:

armasm test.s
armlink -o test.axf --scatter scatter.txt test.o

Generates:

Warning: L6221E: Execution region ER2 with Execution range [0x00008004,0x00008010) overlaps with Execution region ER3 with Load range [0x00008004,0x00008008).

The linker might emit warning message L6221E when an execution region base address overlaps with the load address of another region. This could be due to an incorrect scatter file. The memory map of the image has a load view and an execution view, described by the scatter-loading file. A non-ZI section must have a unique load address and in most cases must have a unique execution address. From RVCT v3.1 onwards, the linker no longer assigns space to ZI execution regions. Therefore this warning might be because a load region LR2 with a relative base address immediately follows a ZI execution region in a load region LR1.

Because the overlapping part might not have real code or data inside, the warning might be harmless.

From RVCT v4.0 build 821 onwards, you can use the following linker options to find out the addresses of each region, and any regions that overlap with a load region:

--load_addr_map_info --map --list=map.txt

You can do one of the following:

  • Ignore the warning, only if after analysis it is possible to determine that the execution region is not going to corrupt the load region that has not yet been copied to its execution region address. Also, debug the application to confirm that it initializes and executes correctly.

  • Adjust the base addresses of the execution regions.

  • Use the FIXED scatter-loading attribute to make the load regions and execution regions have the same base addresses.

See the following in the armlink User Guide:

L6222E: Partial object cannot have multiple ENTRY sections, <e_oname>(<e_sname>) and <oname>(<sname>).

Where objects are being linked together into a partially-linked object, only one of the sections in the objects can have an entry point.

Note:

It is not possible in this case to use the linker option --entry to select one of the entry points.

L6223E: Ambiguous selectors found for <objname>(<secname>) from Exec regions <region1> and <region2>.

This occurs if the scatter file specifies <objname>(<secname>) to be placed in more than one execution region. This can occur accidentally when using wildcards (*). The solution is to make the selections more specific in the scatter file.

L6224E: Could not place <objname>(<secname>) in any Execution region.

This occurs if the linker cannot match an input section to any of the selectors in your scatter file. You must correct your scatter file by adding an appropriate selector.

See the following in the armlink User Guide:

Section placement with the linker.

L6225E: Number <str...> is too long.
L6226E: Missing base address for region <regname>.
L6227E: Using --reloc with --rw-base without --split is not allowed.

See the following in the armlink User Guide:

L6228E: Expected '<str1>', found '<str2>'.
L6229E: Scatter description <file> is empty.
L6230E: Multiple execution regions (<region1>,<region2>) cannot select <secname>.
L6231E: Missing module selector.
L6232E: Missing section selector.
L6233E: Unknown section selector '+<selector>'.
L6234E: <ss> must follow a single selector.

For example, in a scatter file:

:
* (+FIRST, +RO)
:

+FIRST means place this (single) section first. Selectors that can match multiple sections (for example, +RO or +ENTRY) are not permitted to be used with +FIRST (or +LAST). If used together, the error message is generated.

L6235E: More than one section matches selector - cannot all be FIRST/LAST.

See the following in the armlink User Guide:

L6236E: No section matches selector - no section to be FIRST/LAST.

The scatter file specifies a section to be +FIRST or +LAST, but that section does not exist, or has been removed by the linker because it believes it to be unused. Use the linker option --info unused to reveal which objects are removed from your project. Example:

ROM_LOAD 0x00000000 0x4000
{
 ROM_EXEC 0x00000000
 {
   vectors.o (Vect, +First) << error here
   * (+RO)
 }
 RAM_EXEC 0x40000000
 {
   * (+RW, +ZI)
 }
}

Some possible solutions are:

  • Ensure vectors.o is specified on the linker command line.

  • Link with --keep vectors.o to force the linker not to remove this, or switch off this optimization entirely, with --no_remove. ARM® does not recommend this.

  • ARM recommends that you add the ENTRY directive to vectors.s, to tell the linker that it is a possible entry point for your application. For example:

    AREA Vect, CODE
    ENTRY ; define this as an entry point
    Vector_table
    ...
    

    Then link with --entry Vector_table to define the real start of your code.

See the following in the armlink User Guide:

See the following in the armasm User Guide:

ENTRY.

L6237E: <objname>(<secname>) contains relocation(s) to unaligned data.
L6238E: <objname>(<secname>) contains invalid call from '<attr1>' function to '<attr2>' function <sym>.

This linker error is given where a stack alignment conflict is detected in object code. The ABI for the ARM Architecture suggests that code maintains eight-byte stack alignment at its interfaces. This permits efficient use of LDRD and STRD instructions (in ARM architecture 5TE and later) to access eight-byte aligned double and long long data types.

Symbols such as ~PRES8 and REQ8 are Build Attributes of the objects:

  • PRES8 means the object preserves eight-byte alignment of the stack

  • ~PRES8 means the object does not preserve eight-byte alignment of the stack (~ meaning NOT)

  • REQ8 means the object requires eight-byte alignment of the stack.

This link error typically occurs in two cases:

  • Where assembler code (that does not preserve eight-byte stack alignment) calls compiled C/C++ code (that requires eight-byte stack alignment).

  • Where attempting to link legacy objects that were compiled with older tools with objects compiled with recent tools. Legacy objects that do not have these attributes are treated as ~PRES8, even if they do actually happen to preserve eight-byte alignment.

For example:

Error: L6238E: foo.o(.text) contains invalid call from '~PRES8' function to 'REQ8' function foobar

This means that there is a function in the object foo.o (in the section named .text) that does not preserve eight-byte stack alignment, but which is trying to call function foobar that requires eight-byte stack alignment.

A similar warning that might be encountered is:

Warning: L6306W: '~PRES8' section foo.o(.text) should not use the address of 'REQ8' function foobar

where the address of an external symbol is being referred to.

There are two possible solutions to work around this issue:

  • Rebuild all your objects/libraries.

    If you have any assembler files, you must check that all instructions preserve eight-byte stack alignment, and if necessary, correct them.

    For example, change:

    STMFD sp!, {r0-r3, lr} ; push an odd number of registers
    

    to

    STMFD sp!, {r0-r3, r12, lr} ; push even number of registers
    

    The assembler automatically marks the object with the PRES8 attribute if all instructions preserve eight-byte stack alignment, so it is no longer necessary to add the PRESERVE8 directive to the top of each assembler file.

  • If you have any legacy objects/libraries that cannot be rebuilt, either because you do not have the source code, or because the old objects must not be rebuilt (for example, for qualification/certification reasons), then you must inspect the legacy objects to check whether they preserve eight-byte alignment or not.

    Use fromelf -c to disassemble the object code. C/C++ code compiled with ADS 1.1 or later normally preserves eight-byte alignment, but assembled code does not.

    If your objects do indeed preserve eight-byte alignment, then the linker error L6238E can be suppressed with the use of --diag_suppress 6238 on the linker command line.

    By using this, you are effectively guaranteeing that these objects are PRES8.

    The linker warning L6306W is suppressible with --diag_suppress 6306.

See the following FAQ:

8 Byte Stack Alignment.

L6239E: Cannot call non-interworking <t2> symbol '<sym>' in <obj2> from <t1> code in <obj1>(<sec1>)

Example:

Cannot call non-interworking ARM symbol 'ArmFunc' in object foo.o from THUMB code in bar.o(.text)

This problem can be caused by foo.c not being compiled with the option --apcs /interwork, to enable ARM code to call Thumb code (and Thumb to ARM) by linker-generated interworking veneers.

L6241E: <objname>(<secname>) cannot use the address of '<attr1>' function <sym> as the image contains '<attr2>' functions.

When linking with --strict, the linker reports conditions that might fail as errors, for example:

Error: L6241E: foo.o(.text) cannot use the address of '~IW' function main as the image contains 'IW' functions.

IW means interworking, and ~IW means non-interworking.

L6242E: Cannot link object <objname> as its attributes are incompatible with the image attributes.

Each object file generated by the compilation tools includes a set of attributes that indicates the options that it was built with. The linker checks the attributes of each object file it processes. If it finds attributes that are incompatible with those of object files it has loaded previously, it generates this error.

There are two common reasons for this error:

  • Object files compiled with incompatible options. For example:
    • attempting to link one file compiled for Cortex-A processors, with another file compiled for Cortex-M processors.
    • attempting to link files that have incompatible FPU options.
  • Linking objects that have been compiled with an older toolchain that uses an incompatible ABI. See Are legacy objects and libraries compatible with my project? for more information.
L6243E: Selector only matches removed unused sections - no section to be FIRST/LAST.

All sections matching this selector have been removed from the image because they were unused. For more information, use --info unused.

L6244E: <type> region <regionname> address (<addr>) not aligned on a <align> byte boundary.
L6245E: Failed to create requested ZI section '<name>'.
L6248E: <objname>(<secname>) in <attr1> region '<r1>' cannot have <rtype> relocation to <symname> in <attr2> region '<r2>'.

This error can occur when you are trying to build position-independent (PI) code. Consider, for example the following code:

#include <stdio.h>
char *str = "test";
int main(void)
{
    printf ("%s",str);
}

When you compile and link this using:

armcc -c --apcs /ropi/rwpi pi.c
armlink --ropi --rwpi pi.o

the linker reports the following error message:

Error: L6248E: pi.o(.data) in PI region 'ER_RW' cannot have address type relocation to .conststring in PI region 'ER_RO'.

This is because the compiler generates a global pointer str that must be initialized to the address of the string in the .conststring section. However, absolute addresses cannot be used in a PI system, so the link step fails.

To resolve this, you must re-write the code to avoid the explicit pointer. You can do this using either of the following methods:

  • Use a global array instead of a global pointer, for example:

    #include <stdio.h>
    const char str[] = "test";
    int main(void)
    {
        printf ("%s",str);
    }
    
  • Use a local pointer instead of a global pointer, for example:

    #include <stdio.h>
    int main(void)
    {
        char *str = "test";
        printf ("%s",str);
    }
    

Note:

If you are using an array of pointers, such as:

char * list[] = {"zero", "one", "two"};

the linker reports a separate error for each element in the array. In this case, ARM recommends you declare a two dimensional array for the list, with the first dimension as the number of elements in the array, and the second dimension as the maximum size of an element in the array, for example:

char list[3][5] = {"zero", "one", "two"};

You must change the printf() statement to, for example:

printf("%s", list[1]);

See compiler error number 1359.

L6249E: Entry point (<address>) lies within multiple sections.
L6250E: Object <objname> contains illegal definition of special symbol <symbol>.
L6251E: Object <objname> contains illegal reference to special symbol <symbol>.
L6252E: Invalid argument for --xreffrom/--xrefto command: '<arg>'
L6253E: Invalid SYMDEF address: <number>.
L6254E: Invalid SYMDEF type : <type>.

The content of the symdefs file is invalid.

See the following in the armlink User Guide:

Symdefs file format.

L6255E: Could not delete file <filename>: <reason>

An I/O error occurred while trying to delete the specified file. The file was either read-only, or was not found.

L6257E: <object>(<secname>) cannot be assigned to overlaid Execution region '<ername>'.

This message indicates a problem with the scatter file.

See the following in the armlink User Guide:

Scatter file syntax.

L6258E: Entry point (<address>) lies in an overlaid Execution region.

This message indicates a problem with the scatter file.

See the following in the armlink User Guide:

Scatter file syntax.

L6259E: Reserved Word '<name>' cannot be used as a <type> region name.

<name> is a reserved word, so choose a different name for your region.

L6260E: Multiple load regions with the same name (<regionname>) are not allowed.

This message indicates a problem with the scatter file.

See the following in the armlink User Guide:

Scatter file syntax.

L6261E: Multiple execution regions with the same name (<regionname>) are not allowed.

This message indicates a problem with the scatter file.

See the following in the armlink User Guide:

Scatter file syntax.

L6263E: <addr> address of <regionname> cannot be addressed from <pi_or_abs> Region Table in <regtabregionname>

The Region Table contains information used by the C-library initialization code to copy, decompress, or create ZI. This error message is given when the scatter file specifies an image structure that cannot be described by the Region Table.

The error message is most common when PI and non-PI load regions are mixed in the same image.

L6265E: Non-PI Section <obj>(<sec>) cannot be assigned to PI Exec region <er>.

This might be caused by explicitly specifying the wrong ARM library on the linker command-line. Either:

  • remove the explicit specification of the ARM library

  • replace the library, for example, c_t.l, with the correct library.

L6266E: RWPI Section <obj>(<sec>) cannot be assigned to non-PI Exec region <er>.

A file compiled with --apcs=/rwpi is placed in an execution region that does not have the PI attribute.

L6271E: Two or more mutually exclusive attributes specified for Load region <regname>

This message indicates a problem with the scatter file.

L6272E: Two or more mutually exclusive attributes specified for Execution region <regname>

This message indicates a problem with the scatter file.

L6273E: Section <objname>(<secname>) has mutually exclusive attributes (READONLY and ZI)

This message indicates a problem with the object file.

L6275E: COMMON section <obj1>(<sec1>) does not define <sym> (defined in <obj2>(<sec2>))

Given a set of COMMON sections with the same name, the linker selects one of them to be added to the image and discards all others. The selected COMMON section must define all the symbols defined by any rejected COMMON section, otherwise a symbol that was defined by a rejected section would become undefined again. The linker generates an error if the selected copy does not define a symbol that a rejected copy does. This error is normally caused by a compiler fault. Contact your supplier.

L6276E: Address <addr> marked both as <s1>(from <sp1>(<obj1>) via <src1>) and <s2>(from <sp2>(<obj2>) via <src2>).

The image cannot contain contradictory mapping symbols for a given address, because the contents of each word in the image are uniquely typed as ARM ($a) or THUMB ($t) code, DATA ($d), or NUMBER. It is not possible for a word to be both ARM code and DATA. This might indicate a compiler fault. Contact your supplier.

L6277E: Unknown command '<cmd>'.
L6278E: Missing expected <str>.
L6279E: Ambiguous selectors found for <sym> ('<sel1>' and '<sel2>').
L6280E: Cannot rename <sym> using the given patterns.

See the following in the armlink User Guide:

RENAME steering file command.

L6281E: Cannot rename both <sym1> and <sym2> to <newname>.

See the following in the armlink User Guide:

RENAME steering file command.

L6282E: Cannot rename <sym> to <newname> as a global symbol of that name exists (defined) in <obj>).

See the following in the armlink User Guide:

RENAME steering file command.

L6283E: Object <objname> contains illegal local reference to symbol <symbolname>.

An object cannot contain a reference to a local symbol, because local symbols are always defined within the object itself.

L6285E: Non-relocatable Load region <lr_name> contains R-Type dynamic relocations. First R-Type dynamic relocation found in <object>(<secname>) at offset 0x<offset>.

This error occurs where there is a PI reference between two separate segments, if the two segments can be moved apart at runtime. When the linker sees that the two sections can be moved apart at runtime it generates a relocation (an R-Type relocation) that can be resolved if the sections are moved from their statically linked address. However the linker faults this relocation (giving error L6285E) because PI regions must not have relocations with respect to other sections as this invalidates the criteria for being position independent.

L6286E: Relocation #<rel_class>:<rel_number> in <objname>(<secname>) with respect to {symname|%s}. Value(<val>) out of range(<range>) for (<rtype>)

This error typically occurs in the following situations:

  • In handwritten assembly code, where there are not enough bits within the instruction opcode to hold the offset to a symbol.

    For example, the offset range is ±4095 for an ARM state LDR or STR instruction.

  • When the linker is having difficulty placing veneers around a large code section in your image.

    When the linker places a veneer near a very large section it must decide whether to place the veneer before or after the section. When the linker has placed the veneer it might have to place more veneers, which could be placed between the original veneer and its target. This would increase the distance between the veneer and its target.

    The linker automatically allows for modest increases in distances between veneers and their targets. However, a large number of veneers placed between the original veneer and its target might result in the target moving out of range. If this occurs, the linker generates message L6286E.

    To work around this, you can move large code sections away from areas where the linker is placing many veneers. This can be done either by placing large sections in their own regions or by placing them first in the region they are located in using the +FIRST directive in the scatter-loading description file.

    For example:

    LOAD 0x0A000000 0x1000000
    {
       ROM1 +0x0
       {
          *(+RO)
       }
    }
    

    This can be changed to:

    LOAD 0x0A000000 0x1000000
    {
       ROM1 +0x0
       {
          *(+RO)
       }
       ROM1A +0x0
       {
          large.o (+RO)
       }
    }
    
  • When .ARM.exidx exception-handling index tables are placed in different execution regions, or too far from exception handling code.

    The .ARM.exidx exception-handling index tables must be located in a single execution region. Also, the distance from these tables to the C++ code that uses C++ exception handling must be within the range -0x40000000 to 0x3fffffff. Otherwise, the linker reports the following error:

    L6286: Value(0x9ff38980) out of range(-0x9ff38980) out of range(-0x40000000 - 0x3fffffff) for relocation #0 (R_ARM_PREL31), wrt symbol xxx in XXXX.o(.ARM.exidx)

    This behavior is specified in the Exception Handling ABI for the ARM Architecture (EHABI). The EHABI states that the R_ARM_PREL31 relocation, which .ARM.exidx uses, does not use the highest bit (bit 31) for calculating the relocation.

    The most likely cause of this is that C++ code that must access the .ARM.exidx sections, has been split and placed into separate execution regions, outside of the valid range (-0x40000000 to 0x3fffffff).

    To resolve this error, if you have memory between the separated execution regions, place the .ARM.exidx section there with the selector *(.ARM.exidx). For example:

    LOAD_ROM 0x00000000
    {
       ER1 0x00000000   ; The distance from ER2 to ER1 is out of
       {                ; range. 
          file1.o (+RO) ; From a C++ source.
          * (+RO)
       }
       ERx 0x30000000
       {
          *(.ARM.exidx) ; ARM.exidx to ER1 and ER2 both in range.
       }
       ER2 0x60000000 
       {
          file2.o (+RO) ; From a C++ source.
       }
       ER3 +0
       {
          * (+RW, +ZI)
       }
    }

    Otherwise, try placing the code into an execution region close enough to the tables (within the range of -0x40000000 to 0x3fffffff).

In other cases, make sure you have the latest patch installed from Downloads.

For more information, see the following:

What does "Error: L6286E: Value out of range for relocation" mean?

Exception Handling ABI for the ARM Architecture.

L6287E: Illegal alignment constraint (<align>) specified for <objname>(<secname>).

An illegal alignment was specified for an ELF object.

L6291E: Cannot assign Fixed Execution Region <ername> Load Address:<addr>. Load Address must be greater than or equal to next available Load Address:<load_addr>.

See the following in the armlink User Guide:

Execution region attributes.

L6292E: Ignoring unknown attribute '<attr>' specified for region <regname>.

This error message is specific to execution regions with the FIXED attribute. FIXED means make the load address the same as the execution address. The linker can only do this if the execution address is greater than or equal to the next available load address within the load region.

See the following in the armlink User Guide:

L6294E: <type> region <regionname> spans beyond 32 bit address space (base <base>, size <size> bytes).

This error message relates to a problem with the scatter file.

L6295E: Relocation #<rel_class>:<rel_number> in <objname>(<secname>) with respect to <symname> SBREL relocation requires image to be RWPI
L6296E: Definition of special symbol <sym1> is illegal as symbol <sym2> is absolute.

See L6188E.

L6300W: Common section <object1>(<section1>) is larger than its definition <object2>(<section2>).

This might indicate a compiler fault. Contact your supplier.

L6301W: Could not find file <filename>: <reason>

The specified file was not found in the default directories.

L6302W: Ignoring multiple SHLNAME entry.

There can be only one SHLNAME entry in an edit file. Only the first such entry is accepted by the linker. All subsequent SHLNAME entries are ignored.

L6304W: Duplicate input file <filename> ignored.

The specified filename occurred more than once in the list of input files.

L6305W: Image does not have an entry point. (Not specified or not set due to multiple choices.)

The entry point for the ELF image was either not specified, or was not set because there was more than one section with an entry point linked-in. You must use linker option --entry to specify the single, unique entry, for example:

--entry 0x0

or

--entry <label>

The label form is typical for an embedded system.

L6306W: '<attr1>' section <objname>(<secname>) should not use the address of '<attr2>' function <sym>.

See L6238E.

L6307W: Relocation #<rel_class>:<rel_num> in <objname>(<secname>) with respect to <sym>. Branch to unaligned destination.
L6308W: Could not find any object matching <membername> in library <libraryname>.

The name of an object in a library is specified on the link-line, but the library does not contain an object with that name.

L6309W: Library <libraryname> does not contain any members.

A library is specified on the linker command-line, but the library does not contain any members.

L6310W: Unable to find ARM libraries.

This is most often caused by incorrect arguments to --libpath or an invalid value for the environment variable ARMCC5LIB, if defined.

Set the correct path with either the --libpath linker option or the ARMCC5LIB environment variable. The default path for a Windows installation is:

install_directory\lib

Ensure this path does not include any of the following:

  • \armlib

  • \cpplib

  • any trailing slashes (\) at the end. These are added by the linker automatically.

Use --verbose or --info libraries to display where the linker is attempting to locate the libraries.

See the following in the armlink User Guide:

See the following in the Getting Started Guide:

L6311W: Undefined symbol <symbol> (referred from <objname>).

See L6218E.

L6312W: Empty <type> region description for region <region>
L6313W: Using <oldname> as an section selector is obsolete. Please use <newname> instead.

For example, use of IWV$$Code within the scatter file is obsolete. Replace IWV$$Code with Veneer$$Code.

L6314W: No section matches pattern <module>(<section>).

For example:

No section matches pattern foo.*o(ZI).

This can be caused by any of the following:

  • The file foo.o is mentioned in your scatter file, but it is not listed on the linker command line. To resolve this, add foo.o to the link line.

  • You are trying to place the ZI data of foo.o using a scatter file, but foo.o does not contain any ZI data. To resolve this, remove the +ZI attribute from the foo.o line in your scatter file.

  • You have used __attribute__((at(address))) in your source code to place code and data at a specific address. You have also specified *(.ARM.__AT_address) in a scatter file, but you have not specified the address as eight hexadecimal digits. For example, if you specify __attribute__((at(0x10000))) in your source code, then you must specify the section name as *(.ARM.__AT_0x00010000) in the scatter file.

See the following in the armlink User Guide:

L6315W: Ignoring multiple Build Attribute symbols in Object <objname>.

An object can contain at most one absolute BuildAttribute$$... symbol. Only the first such symbol from the object symbol table is accepted by the linker. All subsequent ones are ignored.

L6316W: Ignoring multiple Build Attribute symbols in Object <objname> for section <sec_no>

An object can contain at most one BuildAttribute$$... symbol applicable to a given section. Only the first such symbol from the object symbol table is accepted by the linker. All subsequent ones are ignored.

L6317W: <objname>(<secname>) should not use the address of '<attr1>' function <sym> as the image contains '<attr2>' functions.
L6318W: <objname>(<secname>) contains branch to a non-code symbol <sym>.

This warning means that in the (usually assembler) file, there is a branch to a non-code symbol (in another AREA) in the same file. This is most likely a branch to a label or address where there is data, not code.

For example:

 AREA foo, CODE
 B bar
 AREA bar, DATA
 DCD 0
 END

This results in the message:

init.o(foo) contains branch to a non-code symbol bar.

If the destination has no name:

BL 0x200 ; Branch with link to 0x200 bytes ahead of PC

the following message is displayed:

bootsys.o(BOOTSYS_IVT) contains branch to a non-code symbol <Anonymous Symbol>.

This warning can also appear when linking objects generated by GCC. GCC uses linker relocations for references internal to each object. The targets of these relocations might not have appropriate mapping symbols that permit the linker to determine whether the target is code or data, so a warning is generated. By contrast, armcc resolves all such references at compile-time.

L6319W: Ignoring <cmd> command. Cannot find section <objname>(<secname>).

For example, when building a Linux application, you might have:

--keep *(.init_array)

on the linker command-line in your makefile, but this section might not be present when building with no C++, in which case this warning is reported:

Ignoring --keep command. Cannot find section *(.init_array)

You can often ignore this warning, or suppress it with --diag_suppress 6319.

L6320W: Ignoring <cmd> command. Cannot find argument '<argname>'.
L6323W: Relocation #<rel_class>:<rel_number> in <objname>(<secname>) with respect to <sym>. Multiple variants exist. Using the <type> variant to resolve ambiguity
L6324W: Ignoring <attr> attribute specified for Load region <regname>.

This attribute is applicable to execution regions only. If specified for a Load region, the linker ignores it.

L6325W: Ignoring <attr> attribute for region <regname> which uses the +offset form of base address.

This attribute is not applicable to regions using the +offset form of base address. If specified for a region, which uses the +offset form, the linker ignores it.

A region that uses the +offset form of base address inherits the PI, RELOC, or OVERLAY attributes from either:

  • the previous region in the description

  • the parent load region if it is the first execution region in the load region.

See the following in the armlink User Guide:

L6326W: Ignoring ZEROPAD attribute for non-root execution region <ername>.

ZEROPAD only applies to root execution regions. A root region is a region whose execution address is the same as its load address, and so does not require moving or copying at run-time.

See the following in the armlink User Guide:

Execution region attributes.

L6329W: Pattern <module>(<section>) only matches removed unused sections.

All sections matching this pattern have been removed from the image because they were unused. For more information, use --info unused.

See the following in the armlink User Guide:

L6330W: Undefined symbol <symbol> (referred from <objname>). Unused section has been removed.

This means that an unused section has had its base and limit symbols referenced. For more information, use --info unused.

For example, when using a scatter file to place code and data with RVCT 2.1 or later, the linker reports this error if the scatter file includes the linker-generated table ZISection$$Table. In RVCT 2.1, a new region tables format was introduced which no longer contains ZISection$$Table.

See the following in the armlink User Guide:

L6331W: No eligible global symbol matches pattern <pat>.
L6332W: Undefined symbol <sym1> (referred from <obj1>). Resolved to symbol <sym2>.
L6334W: Overalignment <overalignment> for region <regname> cannot be negative.

See the following in the armlink User Guide:

Overalignment of execution regions and input sections.

L6335W: ARM interworking code in <objname>(<secname>) may contain invalid tailcalls to ARM non-interworking code.

The compiler is able to perform tailcall optimization for improved code size and performance. However, there is a problematic sequence for ARMv4T code in which a Thumb interworking (IW) function calls (by a veneer) an ARM IW function, which tailcalls an ARM non-interworking (~IW) function. The return from the ARM non-IW function can pop the return address off the stack into the PC instead of using the correct BX instruction. The linker can detect this situation and report this warning.

Thumb IW tailcalls to Thumb non-IW do not occur because Thumb tailcalls with B are so short ranged that they can only be generated to functions in the same ELF section which must also be Thumb.

The warning is pessimistic in that an object might contain invalid tailcalls, but the linker cannot be sure because it only looks at the attributes of the objects, not at the contents of their sections.

To avoid the warning, either recompile your entire code base, including any user libraries, with --apcs /interwork, or manually inspect the ARM IW function to check for tailcalls (that is, where function calls are made using an ordinary branch B instruction), to check whether this is a real problem. This warning can be suppressed with --diag_suppress L6335W.

L6337W: Common code sections <o1>(<s1>) and <o2>(<s2>) have incompatible floating-point linkage
L6339W: Ignoring RELOC attribute for execution region <er_name>.

Execution regions cannot explicitly be given the RELOC attribute. They can only gain this attribute by inheriting it from the parent load region or the previous execution region if using the +offset form of addressing.

See the following in the armlink User Guide:

Execution region attributes.

L6340W: options first and last are ignored for link type of <linktype>

The --first and --last options are meaningless when creating a partially-linked object.

L6366E: <object> attributes<attr> are not compatible with the provided cpu and fpu attributes<cli> <diff>.
L6367E: <object>(<section>) attributes<attr> are not compatible with the provided cpu and fpu attributes<cli> <diff>
L6368E: <symbol> defined in <object>(<section>) attributes<attr> are not compatible with the provided cpu and fpu attributes<cli> <diff>
L6369E: <symbol> defined in <object>(ABSOLUTE) are not compatible with the provided cpu and fpu Attributes<cli> <diff>
L6370E: cpu <cpu> is not compatible with fpu <fpu>

See the following in the armlink User Guide:

L6371E: Adding attributes from cpu and fpu: <attrs>
L6372E: Image needs at least one load region.
L6373E: libattrs.map file not found in System Library directory <dir>. Library selection may be impaired.
L6384E: No Load Execution Region of name <region> seen yet at line <line>.

This might be because you have used the current base address in a limit calculation in a scatter file. For example:

ER_foo 0 ImageBase(ER_foo)
L6385W: Addition overflow on line <line>
L6386E: Exec Region Expressions can only be used in base address calculations on line <line>
L6387E: Load Region Expressions can only be used in ScatterAssert expressions on line <line>

See the following in the armlink User Guide:

ScatterAssert function and load address related functions.

L6388E: ScatterAssert expression <expr> failed on line <line>

See the following in the armlink User Guide:

ScatterAssert function and load address related functions.

L6389E: Load Region <name> on line <line> not yet complete, cannot use operations that depend on length of region
L6390E: Conditional operator (expr) ? (expr) : (expr) on line <line> has no : (expr).

See the following in the armlink User Guide:

L6404W: FILL value preferred to combination of EMPTY, ZEROPAD and PADVALUE for Execution Region <name>.

See the following in the armlink User Guide:

Execution region attributes.

L6405W: No .ANY selector matches Section <name>(<objname>).

See the following in the armlink User Guide:

Placement of unassigned sections with the .ANY module selector.

L6406W: No space in execution regions with .ANY selector matching Section <name>(<objname>).

This occurs if there is not sufficient space in the scatter file regions containing .ANY to place the section listed. You must modify your scatter file to ensure there is sufficient space for the section.

See the following in the armlink User Guide:

Placement of unassigned sections with the .ANY module selector.

L6407W: Sections of aggregate size 0x<size> bytes could not fit into .ANY selector(s).

This warning identifies the total amount of image data that cannot be placed in any .ANY selectors.

For example, .ANY(+ZI) is placed in an execution region that is too small for the amount of ZI data:

ROM_LOAD 0x8000
{
    ROM_EXEC 0x8000
    {
        .ANY(+RO,+RW)
    }
    RAM +0 0x{...} <<< region max length is too small
    {
        .ANY(+ZI)
    }
}

See the following in the armlink User Guide:

Placement of unassigned sections with the .ANY module selector.

L6408W: Output is --fpic yet section <sec> from <obj> has no FPIC attribute.
L6409W: Output is --fpic yet object <obj> has no FPIC attribute.
L6410W: Symbol <sym> with non STV_DEFAULT visibility <vis> should be resolved statically, cannot use definition in <lib>.
L6411W: No compatible library exists with a definition of startup symbol <name>.
L6412W: Disabling merging for section <sec> from object <obj>, non R_ARM_ABS32 relocation from section <srcsec> from object <srcobj>
L6413W: Disabling merging for section <sec> from object <obj>, Section contains misaligned string(s).
L6414E: --ropi used without --rwpi or --rw-base.

See the following in the armlink User Guide:

L6415E: Could not find a unique set of libraries compatible with this image. Suggest using the --cpu option to select a specific library.

See the following in the armlink User Guide:

--cpu=name.

L6416E: Relocation <type> at <relclass>:<idx> <objname>(<secname>) cannot be veneered as it has an offset <offset> from its target.
L6417W: Relocation #<rel_class>:<rel_number> in <objname>(<secname>) is with respect to a reserved tagging symbol(#<idx>).
L6418W: Tagging symbol <symname> defined in <objname>(<secname>) is not recognized.
L6419W: Undefined symbol <symbol> (referred from <objname>) imported.
L6420E: Ignoring <oepname>(<secname>:<secnum>) as it is not of a recognized type.
L6422U: PLT generation requires an architecture with ARM instruction support.

For the linker to generate a Procedure Linkage Table (PLT), you must be using a target that supports the ARM instruction set. For example, the linker cannot generate a PLT for a Cortex-M3 target.

L6423E: Within the same collection, section <secname> cannot have different sort attributes.
L6424E: Within the same collection, section <secname1> and section <secname2> cannot be separated into different execution regions.
L6425E: Within the same collection, section <secname> cannot have their section names with different length.
L6426E: Within the same collection, section <secname> cannot have its name duplicated.
L6427E: Cannot rename <sym> to <newname> as it has already been renamed to <name>).
L6429U: Attempt to set maximum number of open files to <val> failed with error code <error>.

An attempt to increase the number of file handles armlink can keep open at any one time has failed.

L6431W: Ignoring incompatible enum size attribute on Symbol <symbol> defined in <object>(<section>).
L6432W: Ignoring incompatible enum size attribute on Object <object>(<section>).
L6433W: Ignoring incompatible enum size attribute on object <object>.
L6434W: Ignoring incompatible wchar_t size attribute on Symbol <symbol> defined in <object>(<section>).
L6435W: Ignoring incompatible wchar_t size attribute on Section <object>(<section>).
L6436W: Ignoring incompatible wchar_t size attribute on object <object>.
L6437W: Relocation #<rel_class>:<idx> in <objname>(<secname>) with respect to <armsym>. Branch relocation to untyped symol in object <armobjname>, target state unknown.
L6438E: __AT section <objname>(<secname>) address <address> must be at least 4 byte aligned.
L6439W: Multiply defined Global Symbol <sym> defined in <objname>(<secname>) rejected in favour of Symbol defined in <selobj>(<selsec>).
L6440E: Unexpected failure in link-time code generation
L6441U: System call to get maximum number of open files failed <error>.
L6442U: Linker requires a minimum of <min> open files, current system limit is <max> files.
L6443W: Data Compression for region <region> turned off. Region contains reference to symbol <symname> which depends on a compressed address.

The linker requires the contents of a region to be fixed before it can be compressed and cannot modify it after it has been compressed. Therefore a compressible region cannot refer to a memory location that depends on the compression process.

L6444I: symbol visibility : <symname> set to <visibility>.
L6445I: symbol visibility : <symname> merged to <set_vis> from existing <old_vis> and new <new_vis>.
L6447E: SHT_PREINIT_ARRAY sections are not permitted in shared objects.
L6448W: While processing <filename>: <message>
L6449E: While processing <filename>: <message>
L6450U: Cannot find library <libname>.
L6451E: <object> built permitting Thumb is forbidden in an ARM-only link.
L6452E: <object>(<section>) built permitting Thumb is forbidden in an ARM-only link.
L6453E: <symbol> defined in <object>(<section>) built permitting Thumb is forbidden in an ARM-only link.
L6454E: <symbol> defined in <object>(ABSOLUTE) built permitting Thumb is forbidden in an ARM-only link.
L6455E: Symbol <symbolname> has deprecated ARM/Thumb Synonym definitions (by <object1> and <object2>).
L6459U: Could not create temporary file.
L6462E: Reference to <sym> from a shared library only matches a definition with Hidden or Protected Visibility in Object <obj>.
L6463U: Input Objects contain <archtype> instructions but could not find valid target for <archtype> architecture based on object attributes. Suggest using --cpu option to select a specific cpu.

See the following in the armlink User Guide:

--cpu=name.

L6464E: Only one of --dynamic_debug, --emit-relocs and --emit-debug-overlay-relocs can be selected.

See the following in the armlink User Guide:

L6467W: Library reports remark: <msg>
L6468U: Only --pltgot=direct or --pltgot=none supported for --base_platform with multiple Load Regions containing code.

See the following in the armlink User Guide:

L6469E: --base_platform does not support RELOC Load Regions containing non RELOC Execution Regions. Please use +0 for the Base Address of Execution Region <ername> in Load Region <lrname>.

See the following in the armlink User Guide:

L6470E: PLT section <secname> cannot be moved outside Load Region <lrname>.
L6471E: Branch Relocation <rel_class>:<idx> in section <secname> from object <objname> refers to ARM Absolute <armsym> symbol from object <armobjname>, Suppress error to treat as a Thumb address.
L6475W: IMPORT/EXPORT commands ignored when --override_visibility is not specified

The symbol you are trying to export, either with an EXPORT command in a steering file or with the --undefined_and_export command-line option, is not exported because of low visibility.

See the following in the armlink User Guide:

L6616E: Cannot increase size of RegionTable <sec_name> from <obj_name>
L6617E: Cannot increase size of ZISectionTable <sec_name> from <obj_name>
L6629E: Unmatched parentheses expecting ) but found <character> at position <col> on line <line>

This message indicates a parsing error in the scatter file.

L6630E: Invalid token start expected number or ( but found <character> at position <col> on line <line>

This message indicates a parsing error in the scatter file.

L6631E: Division by zero on line <line>

This message indicates an expression evaluation error in the scatter file.

L6632W: Subtraction underflow on line <line>

This message indicates an expression evaluation error in the scatter file.

L6634E: Pre-processor command in '<filename>'too long, maximum length of <max_size>

This message indicates a problem with pre-processing the scatter file.

L6635E: Could not open intermediate file '<filename>' produced by pre-processor: <reason>

This message indicates a problem with pre-processing the scatter file.

L6636E: Pre-processor step failed for '<filename>'

This message indicates a problem with pre-processing the scatter file.

L6637W: No input objects specified. At least one input object or library(object) must be specified.

At least one input object or library(object) must be specified.

L6638U: Object <objname> has a link order dependency cycle, check sections with SHF_LINK_ORDER
L6640E: PDTTable section not least static data address, least static data section is <secname>

Systems that implement shared libraries with RWPI use a process data table (PDT). It is created at static link time by the linker and must be placed first in the data area of the image.

This message indicates that the scatter file does not permit placing the PDT first in the data area of the image.

To avoid the message, adjust your scatter file so that the PDT is placed correctly. This message can also be triggered if you accidentally build object files with --apcs=/rwpi.

L6642W: Unused virtual function elimination might not work correctly, because <obj_name> has not been compiled with --vfe
L6643E: The virtual function elimination information in section <sectionname> refers to the wrong section.

This message might indicate a compiler fault. Contact your supplier.

L6644E: Unexpectedly reached the end of the buffer when reading the virtual function elimination information in section <oepname>(<sectionname>).

This message might indicate a compiler fault. Contact your supplier.

L6645E: The virtual function elimination information in section <oepname>(<sectionname>) is incorrect: there should be a relocation at offset <offset>.

This message might indicate a compiler fault. Contact your supplier.

L6646W: The virtual function elimination information in section <oepname>(<sectionname>) contains garbage from offset <offset> onwards.

This message might indicate a compiler fault. Contact your supplier.

L6647E: The virtual function elimination information for <vcall_objectname>(<vcall_sectionname>) incorrectly indicates that section <curr_sectionname>(object <curr_objectname>), offset <offset> is a relocation (to a virtual function or RTTI), but there is no relocation at that offset.

This message might indicate a compiler fault. Contact your supplier.

L6649E: EMPTY region <regname> must have a maximum size.

See the following in the armlink User Guide:

Execution region attributes.

L6650E: Object <objname> Group section <sectionidx> contains invalid symbol index <symidx>.
L6651E: Section <secname> from object <objname> has SHF_GROUP flag but is not member of any group.
L6652E: Cannot reverse Byte Order of Data Sections, input objects are <inputendian> requested data byte order is <dataendian>.
L6654E: Rejected Local symbol <symname> referred to from a non group member <objname>(<nongrpname>)

This message might indicate a compiler fault. Contact your supplier.

L6656E: Internal error: the vfe section list contains a non-vfe section called <oepname>(<secname>).

This message might indicate a compiler fault. Contact your supplier.

L6664W: Relocation #<rel_class>:<rel_number> in <objname>(<secname>) is with respect to a symbol(#<idx> before last Map Symbol #<last>).
L6665W: Neither Lib$$Request$$armlib Lib$$Request$$cpplib defined, not searching ARM libraries.

The following code produces this warning:

  AREA Block, CODE, READONLY
  EXPORT func1
  ;IMPORT ||Lib$$Request$$armlib||
  IMPORT printf
func1
  LDR r0,=string
  BL printf
  BX lr
  AREA BlockData, DATA
string DCB "mystring"
  END

The linker has not been told to look in the libraries and so cannot find the symbol printf.

This also causes the following error:

L6218E: Undefined symbol printf (referred from L6665W.o).

If you do not want the libraries, then ignore this message. Otherwise, to fix both the error and the warning uncomment the line:

IMPORT ||Lib$$Request$$armlib||
L6679W: Data in output ELF section #<sec> '<secname>' was not suitable for compression (<data_size> bytes to <compressed_size> bytes).
L6682E: Merge Section <oepname>(<spname>) is a code section
L6683E: Merge Section <oepname>(<spname>) has an element size of zero
L6684E: Section <spname> from object <oepname> has SHF_STRINGS flag but not SHF_MERGE flag
L6685E: Section <spname> from object <oepname> has a branch reloc <rel_idx> to a SHF_MERGE section
L6688U: Relocation #<rel_class>:<rel_idx> in <oepname>(<spname>) references a negative element
L6689U: Relocation #<rel_class>:<rel_idx> in <oepname>(<spname>). Destination is in the middle of a multibyte character
L6690U: Merge Section <spname> from object <oepname> has no symbols
L6703W: Section <er> implicitly marked as non-compressible.
L6707E: Padding value not specified with PADVALUE attribute for execution region <regionname>.

See the following in the armlink User Guide:

Execution region attributes.

L6708E: Could not process debug frame from <secname> from object <oepname>.
L6709E: Could not associate fde from <secname> from object <oepname>.
L6713W: Function at offset <offset> in <oepname>(<secname>) has no symbol.
L6714W: Exception index table section .ARM.exidx from object <oepname> has no data.
L6720U: Exception table <spname> from object <oepname> present in image, --noexceptions specified.

See the following in the armlink User Guide:

--exceptions, --no_exceptions.

L6721E: Section #<secnum> '<secname>' in <oepname> is not recognized and cannot be processed generically.
L6725W: Unused virtual function elimination might not work correctly, because there are dynamic relocations.
L6728U: Link order dependency on invalid section number <to> from section number <from>.
L6730W: Relocation #<rel_class>:<index> in <objname>(<secname>) with respect to <name>. Symbol has ABI type <type>, legacy type <legacy_type>.

This warning relates to a change in linker behavior between RVCT 2.0 and 2.1.

Note:

The following example produces a warning message only when --strict_relocations is used, or when the input objects are from RVCT 2.0 or earlier.

Example:

    AREA foo, CODE, READONLY
    CODE32
    ENTRY
    KEEP
func proc
    NOP
    ENDP
    DCD foo
    END

In RVCT 2.0 and earlier, the linker determines whether interworking is needed based on the content, which in this example is ARM code. In RVCT 2.1 and later, the linker follows the ABI, which defines that it is the type of the symbol, in this example STT_SECTION (which is interpreted as data), that determines whether interworking is applied.

The simplest solution is to move the data into a separate data area in the assembly source file.

Alternatively, you can use --diag_suppress 6730 to suppress this warning.

L6731W: Unused virtual function elimination might not work correctly, because the section referred to from <secname> does not exist.
L6733W: <objname>(<secname>) contains offset relocation from <lr1name> to <lr2name>, load regions must be rigidly relative.
L6738E: Relocation #<rel_class>:<relocnum> in <oepname>(<secname>) with respect to <wrtsym> is a GOT-relative relocation, but _GLOBAL_OFFSET_TABLE_ is undefined.

Some GNU produced images can refer to the symbol named _GLOBAL_OFFSET_TABLE_. If there are no GOT Slot generating relocations and the linker is unable to pick a suitable address for the GOT base the linker issues this error message.

L6739E: Version '<vername>' has a dependency to undefined version '<depname>'.
L6740W: Symbol '<symname>' versioned '<vername>' defined in '<symverscr>' but not found in any input object.
L6741E: Versioned symbol binding should be 'local:' or 'global:'.
L6742E: Symbol '<symname>' defined by '<oepname>'. Cannot not match to default version symbol '<defversym>'
L6743E: Relocation #<rel_class>:<index> in <oepname>(<spname>) with respect to <symname> that has an alternate def. Internal consistency check failed
L6744E: Relocation #<rel_class>:<index> <oepname>(<spname>) with respect to undefined symbol <symname>. Internal consistency check:
L6745E: Target CPU <cpuname> does not Support ARM, <objname>(<secname>) contains ARM code
L6747W: Raising target architecture from <oldversion> to <newversion>.

If the linker detects objects that specify the obsolete ARMv3, it upgrades these to ARMv4 to be usable with ARM libraries.

L6748U: Missing dynamic array, symbol table or string table in file <oepname>.
L6751E: No such sorting algorithm <str> available.
L6753E: CallTree sorting needs Entry Point to lie within a CallTree Sort ER.
L6761E: Removing symbol <symname>.
L6762E: Cannot build '<type>' PLT entries when building a <imgtype>.
L6763W: '<optname>' cannot be used when building a shared object or DLL. Switching it off
L6764E: Cannot create a PLT entry for target architecture 4T that calls Thumb symbol <symname>
L6765W: Shared object entry points must be ARM-state when linking architecture 4T objects.

This can occur when linking with GNU C libraries. The GNU startup code crt1.o does not have any build attributes for the entry point, so the linker cannot determine which execution state (ARM or Thumb) the code runs in. Because the GNU C library startup code is ARM code, you can safely ignore this warning, or you can suppress it by using --diag_suppress 6765.

L6766W: PLT entries for architecture 4T do not support incremental linking.
L6769E: Relocation #<rel_class>:<relocnum> in <oepname>(<secname>) with respect to <wrtsym>. No GOTSLOTexists for symbol.
L6770E: The size and content of the dynamic array changed too late to be fixed.
L6771W: <oepname>(<secname>) contains one or more address-type relocations in RO data. Making section RW to be dynamically relocated at run-time.
L6772W: IMPORT <symname> command ignored when building --sysv.

See the following in the armlink User Guide:

L6774W: <objname>(<secname>) has debug frame entries of a bad length.
L6775W: <objname>(<secname>) has FDEs which use CIEs which are not in this section.
L6776W: The debug frame in <objname>(<secname>) does not describe an executable section.
L6777W: The debug frame in <objname>(<secname>) has <actual> relocations (expected <expected>)
L6778W: The debug frame in <objname>(<secname>) uses 64-bit DWARF.
L6780W: <origvis> visibility removed from symbol '<symname>' through <impexp>.
L6781E: Value(<val>) Cannot be represented by partition number <part> for relocation #<rel_class>:<rel_number> (<rtype>, wrt symbol <symname>) in <objname>(<secname>)
L6782W: Relocation #<rel_class>:<relnum> '<rtype>' in <oepname> may not access data correctly alongside <pltgot_type> PLT entries
L6783E: Mapping symbol #<symnum> '<msym>' in <oepname>(<secnum>:<secname>) defined at the end of, or beyond, the section size (symbol offset=0x<moffset>, section size=0x<moffset>, section size=0x<secsize>)

This indicates that the address for a section points to a location at the end of or outside of the ELF section. This can be caused by an empty inlined data section and indicates there might be a problem with the object file. You can use --diag_warning 6783 to suppress this error.

L6784E: Symbol #<symnum> '<symname>' in <oepname>(<secnum>:<secname>) with value <value> has size 0x<size> that extends to outside the section.

The linker encountered a symbol with a size that extends outside of its containing section. This message is only a warning by default in the RVCT 2.2 build 503 and later toolchains. Use --diag_warning 6784 to suppress this error.

L6785U: Symbol '<symname>' marked for import from '<libname>' already defined by '<oepname>'
L6786W: Mapping symbol #<symnum> '<msym>' in <oepname>(<secnum>:<secname>) defined at unaligned offset=0x<moffset>
L6787U: Region table handler '<handlername>' needed by entry for <regionname> was not found.
L6788E: Scatter-loading of execution region <er1name> to [<base1>,<limit1>) will cause the contents of execution region <er2name> at [<base2>,<limit2>) to be corrupted at run-time.

This occurs when scatter-loading takes place and an execution region is put in a position where it partially or wholly overwrites another execution region (which can be itself or another region).

For example, the following code generates this error:

LOAD_ROM 0x0000 0x4000
{
 EXEC1 0x4000 0x4000
 {
 * (+RW,+ZI)
 }
 EXEC2 0x0000 0x4000
 {
 * (+RO)
 }
}

and reports:

Error: L6788E: Scatter-loading of execution region EXEC2 will cause the contents of execution region EXEC2 to be corrupted at run-time.

This code does not generate the error:

LOAD_ROM 0x0000 0x4000
{
 EXEC1 0x0000 0x4000
 {
 * (+RO)
 }
 EXEC2 0x4000 0x4000
 {
 * (+RW,+ZI)
 }
}

See the following in the armlink User Guide:

Information about scatter files.

L6789U: Library <library> member <filename> : Endianness mismatch.
L6790E: Relocation #<rel_class>:<relnum> in <objname>(<secname>) with respect to <symname>. May not IMPORT weak reference through GOT-generating relocation
L6791E: Unknown personality routine <pr> at 0x<offset> <oepname>(<secname>).
L6792E: Descriptor at offset 0x<offset> <oepname>(<secname>).
L6793E: Expecting Landing pad reference at offset 0x<offset> in cleanup descriptor <oepname>(<secname>).
L6794E: Expecting Landing pad reference at offset 0x<offset> in catch descriptor <oepname>(<secname>).
L6795E: Expecting RTTI reference at offset 0x<offset> in catch descriptor <oepname>(<secname>).
L6796E: Descriptor at offset 0x<offset> <oepname>(<secname>) overruns end of section.
L6797E: Data at Offset 0x<offset> in exception table <oepname>(<secname>) overruns end of section
L6798E: Expecting RTTI reference at offset 0x<offset> in Function Specification descriptor <oepname>(<secname>).
L6799E: Expecting Landing Pad reference at offset 0x<offset> in Function Specification descriptor <oepname>(<secname>).

A landing pad is code that cleans up after an exception has been raised. If the linker detects old-format exception tables, it automatically converts them to the new format.

This message does not appear unless you are using a later version of the linker with an earlier version of the compiler.

L6800W: Cannot convert generic model personality routine at 0x<offset> <oepname>(<secname>).

A personality routine unwinds the exception handling stack. If the linker detects old-format exception tables then it automatically converts them to the new format. This message indicates a fault in the compiler. Contact your supplier.

L6801E: <objname>(<secname>) containing <secarmthumb> code cannot use the address of '~IW (The user intended not all code should interwork)' <funarmthumb> function <sym>.

The linker can diagnose where a non-interworking (~IW) function has its address taken by code in the other state. This error is disabled by default, but can be enabled by linking with --strict. The error can be downgraded to a warning with --diag_warning 6801 and subsequently suppressed completely if required with --diag_suppress 6801

Where code, for example, in a.c uses the address of a non-interworking function in t.c:

armcc -c a.c
armcc --thumb -c t.c
armlink t.o a.o --strict

reports:

Error: L6801E: a.o(.text) containing ARM code cannot use the address of '~IW' Thumb function foo.
L6802E: Relocation #<rel_class>:<idx> in <objname>(<secname>) with respect to <armsym>. Thumb Branch to non-Thumb symbol in <armobjname>(<armsecname>).
L6803W: Relocation #<rel_class>:<idx> in <objname>(<secname>) with respect to <armsym>. Thumb Branch is unlikely to reach target in<armobjname>(<armsym>).
L6804W: Legacy use of symbol type STT_TFUNC detected
L6805E: Relocation #<rel_class>:<idx> in <objname>(<secname>) with respect to <armsym>. Branch to untyped Absolute symbol in <armobjname>, target state unknown
L6806W: Relocation #<rel_class>:<idx> in <objname>(<secname>) with respect to <othersym>. Branch to untyped symbol in <otherobjname>(<othersecname>), ABI requires external code symbols to be of type STT_FUNC.
L6807E: Relocation #<rel_class>:<idx> in <objname>(<secname>) with respect to <othersym>. Branch to untyped symbol in same section. State change is required.
L6809W: Relocation <rel_class>:<idx> in <objname>(<secname>) is of deprecated type <rtype>, please see ARMELF for ABI compliant alternative
L6810E: Relocation <rel_class>:<idx> in <objname>(<secname>) is of obsolete type <rtype>

Relocation errors and warnings are most likely to occur if you are linking object files built with previous versions of the ARM tools.

To show relocation errors and warnings, use the --strict_relocations switch. This option enables you to ensure ABI compliance of objects. It is off by default, and deprecated and obsolete relocations are handled silently by the linker.

See the following in the armlink User Guide:

--strict_relocations, --no_strict_relocations.

L6812U: Unknown symbol action type, please contact your supplier.
L6813U: Could not find Symbol <symname> to rename to <newname>.

See the following in the armlink User Guide:

RENAME steering file command.

L6815U: Out of memory. Allocation Size:<alloc_size> System Size:<system_size>.

This error is reported by ARM Compiler v4.1 and later. It provides information about the amount of memory available and the amount of memory required to perform the link step.

This error occurs because the linker does not have enough memory to link your target object. This is not common, but might be triggered for a number of reasons, such as:

  • Linking very large objects or libraries together.

  • Generating a large amount of debug information.

  • Having very large regions defined in your scatter file.

In these cases, your workstation might run out of virtual memory.

This issue might also occur if you use the FIXED scatter-loading attribute. The FIXED attribute forces an execution region to become a root region in ROM at a fixed address. The linker might have to add padding bytes between the end of the previous execution region and the FIXED region, to generate the ROM image. The linker might run out of memory if large amounts of padding are added when the address of the FIXED region is far away from the end of the execution region. The link step might succeed if the gap is reduced.

See the following in the armlink User Guide:

While the linker can generate images of almost any size, it requires a larger amount of memory to run and finish the link. Try the following solutions to improve link-time performance, to avoid the Out of memory error:

  1. Shut down all non-essential applications and processes when you are linking.

    For example, if you are running under Eclipse, try running your linker from the command-line, or exiting and restarting Eclipse between builds.

  2. Use the 64-bit version of the linker.

    If you are using a 64-bit operating system, it is possible to make use of a 64-bit version of armlink.

    See the following in the Getting Started Guide:

    Changing to the 64-bit linker.

  3. Use the --no_debug linker option.

    This command tells the linker to create the object without including any debug information.

    See the following in the armlink User Guide:

    --debug, --no_debug.

    Note:

    It is not possible to perform source level debugging if you use this option.
  4. Reduce debug information.

    If you do not want to use the --no_debug option, there are other methods you can use to try to reduce debug information.

    See the following in the armcc User Guide:

    Methods of reducing debug information in objects and libraries.

    You can also use the fromelf utility to strip debug information from objects and libraries that you do not have to debug.

    See the following in the fromelf User Guide:

    --strip=option[,option,...].

  5. Use partial linking.

    You can use partial linking to split the link stage over a few smaller operations. Doing this also stops duplication of the object files in memory in the final link.

    See the following in the armlink User Guide:

    --partial.

  6. Increase memory support on Windows operating systems.

    On some Windows operating systems it is possible to increase the virtual address space from 2GB (the default) to 3GB.

    For more information, see the following Microsoft article:

    Memory Support and Windows Operating Systems.

  7. Use the --no_eager_load_debug linker option.

    This option is available in RVCT 4.0 build 697 and later. It causes the linker to remove debug section data from memory after object loading. This lowers the peak memory usage of the linker at the expense of some linker performance, because much of the debug data has to be loaded again when the final image is written.

    See the following in the armlink User Guide:

    --eager_load_debug, --no_eager_load_debug.

If you are still experiencing the same problem, raise a support case.

L6828E: Relocation #<rel_class>:<idx> in <objname>(<secname>) with respect to <symname>, Branch source address <srcaddr> cannot reach next available pool at [<pool_base>,<pool_limit>). Please use the --veneer_pool_size option to increase the contingency.

The --veneer_inject_type=pool veneer generation model requires branches to veneers in the pool to be able to reach the pool limit, which is the highest possible address a veneer can use. If a branch is later found that cannot reach the pool limit, and armlink is able to fit all the veneers in the pool into the lower pool limit, then armlink reduces the pool limit to accommodate the branch. Error message L6828 is issued only if armlink is unable to lower the pool limit.

See the following in the armlink User Guide:

--veneer_inject_type=type.

L6898E: Relocation #<rel_class>:<idx> in <objname>(<secname>) with respect to <armsym>. ARM branch to non-ARM/Thumb symbol in <armobjname>(<armsecname>).
L6899E: Existing SYMDEFS file '<filename> 'is read-only.
L6900E: Expected parentheses to specify priority between AND and OR operators.
L6901E: Expected symbol name.
L6902E: Expected a string.
L6903E: Cannot execute '<text>' in '<clause>' clause of script.
L6904E: Destination symbol of rename operation clashes with another rename.
L6905E: Source symbol of rename operation clashes with another rename.
L6906E: (This is the rename operation which it clashes with.)
L6907E: Expected an expression.
L6910E: Expected a phase name.
L6912W: Symbol <symname> defined at index <idx> in <oepname>(<secname>), has ABI symbol type <symtype> which is inconsistent with mapping symbol type <maptype>.
L6913E: Expected execution region name.
L6914W: option <spurious> ignored when using --<memoption>.
L6915E: Library reports error: <msg>

The message is typically one of the following:

  • Error: L6915E: Library reports error: scatter-load file declares no heap or stack regions and __user_initial_stackheap is not defined.
    

    or

    Error: L6915E: Library reports error: The semihosting __user_initial_stackheap cannot reliably set up a usable heap region if scatter loading is in use
    

    It is most likely that you have not re-implemented __user_setup_stackheap() or you have not defined ARM_LIB_STACK or ARM_LIB_HEAP regions in the respective scatter file.

    Note:

    __user_setup_stackheap() supersedes the deprecated function __user_initial_stackheap().

    See the following in the Software Development Guide:

    Placing the stack and heap.

    See the following in the ARM C and C++ Libraries and Floating-Point Support User Guide:

    See the following in the armlink User Guide:

    Reserving an empty region.

  • Error: L6915E: Library reports error: __use_no_semihosting was requested but <function> was referenced. 
    

    Where <function> represents __user_initial_stackheap, _sys_exit, _sys_open, _sys_tmpnam, _ttywrch, system, remove, rename, _sys_command_string, time, or clock.

    This error can appear when retargeting semihosting-using functions, to avoid any SVC or BKPT instructions being linked-in from the C libraries.

    Ensure that no semihosting-using functions are linked in from the C library by using:

    #pragma import(__use_no_semihosting)
    

    See the following in the ARM C and C++ Libraries and Floating-Point Support User Guide:

    Using the libraries in a nonsemihosting environment.

    If there are still semihosting-using functions being linked in, the linker reports this error.

    To resolve this, you must provide your own implementations of these C library functions.

    The emb_sw_dev directory contains examples of how to re-implement some of the more common semihosting-using functions. See the file retarget.c.

    See the following for more information on semihosting-using C library functions:

    ARM C and C++ Libraries and Floating-Point Support User Guide.

    Note:

    The linker does not report any semihosting-using functions such as, for example, __semihost(), in your own application code.

    To identify which semihosting-using functions are still being linked-in from the C libraries:

    1. Link with armlink --verbose --list err.txt
    2. Search err.txt for occurrences of __I$use$semihosting

      For example:

      ...
      Loading member sys_exit.o from c_2.l.
      reference : __I$use$semihosting
      definition: _sys_exit
      ...

      This shows that the semihosting-using function _sys_exit is linked-in from the C library. To prevent this, you must provide your own implementation of this function.

  • Error: L6915E: Library reports error:__use_no_heap was requested, but <reason> was referenced
    

    If <reason> represents malloc, free, __heapstats, or __heapvalid, the use of __use_no_heap conflicts with these functions.

  • Error: L6915E: Library reports error:__use_no_heap_region was requested, but <reason> was referenced
    

    If <reason> represents malloc, free, __heapstats, __heapvalid, or __argv_alloc, the use of __use_no_heap_region conflicts with these functions.

L6916E: Relocation #<rel_class>:<idx> in <oepname>(<spname>). R_ARM_CALL for conditional BL instruction).
L6917E: Relocation #<rel_class>:<idx> in <oepname>(<spname>). R_ARM_JUMP24 for BLX instruction.
L6918W: Execution region <ername> placed at 0x<eraddr> needs padding to ensure alignment <spalign> of <oepname>(<spname>).
L6922E: Section <objname>(<secname>) has mutually exclusive attributes (READONLY and TLS)
L6923E: Relocation #<rel_class>:<idx> in <oepname>(<spname>) with respect to <symname>. TLS relocation <type> to non-TLS symbol in <symobjname>(<symsecname>).
L6924E: Relocation #<rel_class>:<idx> in <oepname>(<spname>) with respect to <symname>. Non-TLS relocation <type> to STT_TLS symbol in <symobjname>(<symsecname>).
L6925E: Ignoring <token> attribute for region <region>. MemAccess support has been removed.
L6926E: Relocation #<rel_class>:<idx> in <oepname>(<spname>) has incorrect relocation type <rtype> for instruction encoding 0x<bl>.
L6927E: Relocation #<rel_class>:<idx> in <oepname>(<spname>) has incorrect relocation type <rtype> for instruction encoding 0x<bl1><bl2>.
L6932W: Library reports warning: <msg>

See the following in the Migration and Compatibility Guide:

Linker changes between RVCT v3.1 and RVCT v4.0.

L6935E: Debug Group contents are not identical, <name> with signature sym <sig> from objects (<new>) and (<old>)
L6936E: Multiple RESOLVE clauses in library script for symbol '<sym>'.
L6937E: Multiple definitions of library script function '<func>'.
L6939E: Missing alignment for region <regname>.
L6940E: Alignment <alignment> for region <regname> must be at least 4 and a power of 2 or MAX.
L6941W: chmod system call failed for file <filename> error <perr>
L6942E: Execution Region <ername> contains multiple <type>, sections:
L6966E: Alignment <alignment> for region <regname> cannot be negative.
L6967E: Entry point (<address>) points to a THUMB instruction but is not a valid THUMB code pointer.
L6968E: Could not parse Linux Kernel version \"<kernel>\".
L6969W: Changing AT Section <name> type from RW to RO in <ername>.
L6971E: <objname>(<secname>) type <type> incompatible with <prevobj>(<prevname>) type <prevtype> in er <ername>.

You might see this message when placing __at sections with a scatter file. For example, the following code in main.c and the related scatter file gives this error:

int variable __attribute__((at(0x200000)));

LR1 0x0000 0x20000
{
    ER1 0x0 0x2000
    {
        *(+RO)
    }
    ER2 0x8000 0x2000
    {
        main.o
    }
    RAM 0x200000 (0x1FF00-0x2000)
    {
        *(+RW, +ZI)
    }
}

The variable has the type ZI, and the linker attempts to place it at address 0x200000. However, this address is reserved for RW sections by the scatter file. This produces the error:

Error: L6971E: stdio_streams.o(.data) type RW incompatible with main.o(.ARM.__AT_0x00200000) type ZI in er RAM.

To fix this, change the address in your source code, for example:

int variable __attribute__((at(0x210000)));

See the following in the armlink User Guide:

L6972E: <objname>(<secname>) with required base 0x<required> has been assigned base address 0x<actual>.
L6973E: Error placing AT section at address 0x<addr> in overlay ER <ername>.

For example, you attempted to use __attribute__((at(address))) to place a section when building a DLL or application with an overlay region. __attribute__((at(address))) requires that you specify a fixed location in a scatter file with .ARM.__at_address. In this case, you must also specify the --no_autoat linker option.

See the following in the armlink User Guide:

L6974E: AT section <name> does not have a base address.

See the following in the armlink User Guide:

Placement of sections at a specific address with __at.

L6975E: <objname>(<secname>) cannot have a required base and SHF_MERGE.
L6976E: <objname>(<secname>) cannot have a required base and SHF_LINK_ORDER.
L6977E: <objname>(<secname>) cannot be part of a contiguous block of sections
L6978W: <objname>(<secname>) has a user defined section type and a required base address.
L6979E: <objname>(<secname>) with required base address cannot be placed in Position Independent ER <ername>.
L6980W: FIRST and LAST ignored for <objname>(<secname>) with required base address.

See the following in the armlink User Guide:

Section placement with the FIRST and LAST attributes.

L6981E: __AT incompatible with BPABI and SystemV Image types

See the following in the armlink User Guide:

Restrictions on placing __at sections.

L6982E: AT section <objname>(<spname>) with base <base> limit <limit> overlaps address range with AT section <obj2name>(<sp2name>) with base <base2> limit <limit2>.

See the following in the armlink User Guide:

Placement of sections at a specific address with __at.

L6983E: AT section <objname>(<spname>) with required base address <base> out of range for ER <ername> with base <erbase> and limit <erlimit>.

This can occur if you specify __attribute__((at(address))) in your code, .ARM.__at_address in your scatter file, and --no_autoat option on the linker command line. In this case, the address part of .ARM.__at_address must be specified as eight hexadecimal digits. For example:

int x1 __attribute__((at(0x4000)));  // defined in function.c
; scatter file
LR1 0x0
{
    ...
        function.o(.ARM.__at_0x00004000)
    ...
}

See the following in the armlink User Guide:

L6984E: AT section <objname>(<spname>) has required base address <base> which is not aligned to section alignment <alignment>.

See the following in the armlink User Guide:

Placement of sections at a specific address with __at.

L6985E: Unable to automatically place AT section <objname>(<spname>) with required base address <base>. Please manually place in the scatter file using the --no_autoat option.

See the following in the armlink User Guide:

Non-ConfidentialPDF file icon PDF versionARM DUI0496M
Copyright © 2010-2016 ARM Limited or its affiliates. All rights reserved.