If the TI linker is used to link certain object files produced by a non-TI compiler, it may incorrectly interpret some relocation entries, and encode incorrect addresses into the linked output file.

The problem lies with REL-type relocations for MOVT instructions. The ELF file format specification describes two kinds of relocations, REL and RELA. RELA relocations have all their data in a separate section; REL relocations have some data in a separate section and some encoded within the instruction subject to the relocation.

ARM MOVT instructions have special relocation types, because of the way that MOVT and MOVW are used to assemble large constants. REL-type MOVT relocations end up being processed slightly differently than other relocations, and the TI linker did not implement that difference correctly.

For TI tools, the bug doesn't matter, because the TI compiler never makes REL-type MOVT relocations; it only makes RELA-type, which have no problems. However, other compilers (gcc is known to be one) do make the problematic relocations, and linking those object files using the TI linker can trigger the bug.

When to worry about this bug:
1. Is the object file compiled with a TI compiler? If yes, then don't worry.
2. Does the output of "armofd --obj_display=none,relocs" for the file contain a relocation whose type includes the string "MOVT"? If no, then don't worry.
3. Look at the output of "armofd -x" for the object file. Find the section whose sh_type field is SHT_REL. A few lines down from the section-header info is a "<relocations>" segment; do any of the listed relocations have an r_type field that contains the string "MOVT"? If no, then don't worry. If yes, then worry, because the situation that triggers the bug exists in that file.