In a shared library an undefined symbol is implicitly imported. If the symbol is called as a function a PLT entry is generated for it. When the caller is a Thumb b.w a thunk to the PLT entry is needed as all PLT entries are in ARM state.
This change allows undefined symbols to have thunks in the same way that shared symbols may have thunks.
I found this after finding segfaults in the Thumb2 release build of various python C extensions. The extensions are built as shared objects
that call back to the python interpreter. The python interpreter symbols are implicitly imported as undefined symbols. If a tail call from Thumb2 is used b.w then the PLT entry (ARM) was entered in Thumb state causing a segfault.
Adding thunks to undefined symbols is straightforward, although it does have the side-effect of adding a template parameter which requires some unrelated code to be updated. I considered trying to convert the undefined symbol to a shared symbol, but decided against it on the grounds that that this might cause problems later on if the non-existent InputFile was ever accessed.
Can you also mention that remaining undefined symbols when creating a DSO are resolved by the dynamic linker, and relocation against such undefined symbols need thunk in some architecture such as AArch64?