In RVCT v3.1 for µVision and earlier, the helper functions reside in libraries provided with the ARM compiler. Therefore, it was possible to use armlib and cpplib in a scatter file to inform the linker where to place these helper functions in memory.

In RVCT v4.0 for µVision and later, the helper functions are generated by the compiler in the resulting object files. They are no longer in the standard C libraries, so it is no longer possible to use armlib and cpplib in a scatter file. Instead, place the helper functions using *.* (i.__ARM_*) in your scatter file.

In RVCT v3.1 for µVision the visibility of a symbol was overridden by the steering file or .directive commands IMPORT and EXPORT. When this occurred the linker issued a warning message, for example:

Warning: L6780W: STV_HIDDEN visibility removed from symbol hidden_symbol through EXPORT.

In RVCT v4.0 for µVision the steering file mechanism respects the visibility of the symbol, so an IMPORT or EXPORT of a STV_HIDDEN symbol is ignored. You can restore the v3.1 behavior with the --override_visibility command-line option.

In the majority of cases region related symbols behave identically to v3.1.

The RVCT v4.0 for µVision linker fully supports reading and writing of the ABI Build Attributes section. The linker can now check more properties such as wchar_t and enum size. This might result in the linker diagnosing errors in old objects that might have inconsistencies in the Build Attributes. Most of the Build Attributes messages can be downgraded to permit armlink to continue.

The --cpu option now checks the FPU attributes if the CPU chosen has a built-in FPU. For example, --cpu=Cortex-R4F implies --fpu=vfpv3_d16. In RVCT v3.1 for µVision the --cpu option only checked the build attributes of the chosen CPU.

The error message L6463E: 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. is given in one of two situations:

If setting the --cpu option still fails, the option --force_explicit_attr causes the linker to retry the CPU mapping using Build Attributes constructed from --cpu=archtype. This might help if the Error is being given solely because of inconsistent Build Attributes.

A change to the linker when dealing with C library initialization code causes specially named sections in the linker map file created with the --map command-line option. You can ignore these specially named sections.

Some error handling code is run later so that information from RW compression can be used. In almost all cases, this means more customer programs are able to link. There is one case where RVCT v4.0 for µVision has removed a special case so that it could diagnose more RW compression errors.

Multiple in-place execution regions with RW compression are no longer a special case. It used to be possible to write:

    LR1 0x0
    {
        ER1 +0 { file1.o(+RW) }
        ER2 +0 { file2.o(+RW) }
    }

This is no longer possible under v4.0 and the linker gives an error message that ER1 decompresses over ER2. This change has been made to permit the linker to diagnose:

    LR1 0x0
    {
        ER1 +0 { file1.o(+RW) }
        ER2 +0 { file2.o(+RO) }   ; NOTE RO not RW
    }

This fails at runtime on RVCT v3.1 for µVision.