R_PPC64_TOC does not have an associated symbol, but does have a non-zero VA that target-specific code must compute using some non-trivial rule. We currently handle this as a special case in PPC64TargetInfo::relocateOne, where we know to write this special address, but does not work when creating shared libraries. The special TOC address needs to be the subject of a R_PPC64_RELATIVE relocation, and so we also need to know how to encode this special address in the addend of that relocation.
Thus, some target-specific logic is necessary when creating R_PPC64_RELATIVE as well. It looks like the best way to solve this problem is to simply have getLocalRelTarget ask the target for the address of special symbolless relocations. This allows us to remove the special case in PPC64TargetInfo::relocateOne (simplifying code there), and naturally allows the existing logic to do the right thing when creating associated R_PPC64_RELATIVE relocations for shared libraries.
Update the comment to mention that we usually return 0 but may be different on PPC64.
But, actually, does this happen on non-PPC64 platform? If there's no other platform that we have to take care of this case, this is probably over-designed. We can define a function like getPPC64TocDefault() and use that function here if it's on PPC64.