When linking a program with --unresolved-symbols=ignore-all, gold should not issue a relocation overflow error for a reference to the symbol. For example, this happens on 64-bit PowerPC. foo.c: void f1() { f2(); } Compile that with a 64-bit PowerPC compiler > ld foo.o: foo.o(.text+0x14): error: relocation overflow foo.o(.text+0x14): error: undefined reference to 'f2' > ld foo.o --unresolved-symbols=ignore-all foo.o(.text+0x14): error: relocation overflow That last error shouldn't be issued. We shouldn't report a relocation overflow for a reference to an undefined symbol if we aren't going to report an error about the undefined symbol. Unfortunately there doesn't seem to be any one point to check. Calls to is_weak_undefined are a proxy, but I'm not sure that all the calls need to be changed.
> That last error shouldn't be issued. We shouldn't report a relocation overflow > for a reference to an undefined symbol if we aren't going to report an error > about the undefined symbol. Why should we report a relocation overflow in either case? -cary
>> That last error shouldn't be issued. We shouldn't report a relocation overflow >> for a reference to an undefined symbol if we aren't going to report an error >> about the undefined symbol. > Why should we report a relocation overflow in either case? You're right, we shouldn't. We should only issue relocation overflow errors for defined symbols. A relocation overflow for an undefined symbol is useless.
Here is my thinking, FWIW. What is the value of an undefined symbol? Why should a branch to zero not report an overflow, if there is indeed an overflow? Try linking the same testcase on x86_64, but with -Ttext=0x100000000. ld/ld-new -o pr18147 pr18147.o --unresolved-symbols=ignore-all -Ttext=0x100000000 ld/ld-new: warning: cannot find entry symbol _start; defaulting to 0000000100000000 pr18147.o: In function `f1': pr18147.c:(.text+0x3): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `f2' gold on x86_64 doesn't report an error, but that is simply because gold on x86_64 doesn't report relocation overflows, a serious defect IMO. gold/ld-new -o pr18147 pr18147.o --defsym f2=0 -Ttext=0x100000000 => no error
We already explicitly do not report relocation errors for weak undefined symbols. That's because in those cases the relocation overflow is not important. And Cary is right: for any sort of undefined symbol, the relocation overflow is not important. What useful information is the linker conveying? I've already said that I don't care whether the symbol is undefined. It follows that any reference to that symbol can be expected to fail, and I don't care. If I'm going to run the program, I must be using some technique to avoid executing that relocation at all. There's no reason to think that I care about a relocation overflow referring to that symbol any more than I care about any other reference to that symbol. This is not the case of --defsym SYM=0. For that case we certainly should report a relocation overflow. This is a case where I've said I don't care about the symbol at all. (The particular use case here is a program that is determining the types of symbols by linking against libraries that define those symbols and examining the debug info. The libraries can be passed as -l options and there is no need for the tool to replicate the linker's search path. There is also no need to worry about the library dependencies, since they aren't relevant for the purpose of the tool. So it uses --unresolved-symbols=ignore-all.)
It might be reasonable to not report relocation overflow for strong undefined symbols, but I don't think that a linker should ignore all weak undefined symbol overflow. For example, this if (foo) foo (); should report overflows in any relocation used to implement "if (foo)". Normally of course any relocations involved are absolute and zero works fine in an absolute relocation, but suppose a pc-relative address calculation is used to implement "if (foo)". That might overflow when foo is undefined if you use -Ttext (or have an extremely large binary).
Actually, I am fine with only ignoring relocation errors against strong undefined symbol in precisely those cases where we already ignore the relocation errors against weak undefined symbols. Those are the only cases that will matter in practice. For example, Target_powerpc<size, big_endian>::Relocate::relocate skips the relocation overflow error for a branch relocation to a weak undefined symbol.
Fixed with commit 282c9750