fix: Error on R_X86_64_32 to DSO symbols in PIE output

[deepakshirkem]

Wild was silently succeeding when R_X86_64_32 or R_X86_64_32S relocations were used against DSO symbols in PIE output. Both GNU ld and lld correctly error with "recompile with -fPIC".

What still needs fixing (#2114)

• R_X86_64_PC32 to DSO symbols in PIE — tricky because it's valid for PLT calls but invalid for data references. Not sure how to distinguish the two cases.
• R_X86_64_64 to local symbols in PIE — lld errors but GNU ld emits R_X86_64_RELATIVE dynamic relocation instead. Not sure which behavior Wild should match.

Help needed

@davidlattimore @lapla-cogito

1. How to distinguish valid vs invalid R_X86_64_PC32 in PIE context
2. Whether R_X86_64_64 to local symbols should error or emit dynamic reloc

Partial fix for #2114

[davidlattimore]

Note that ExpectError implies "RunEnabled:False"

[davidlattimore]

• How to distinguish valid vs invalid R_X86_64_PC32 in PIE context

Possibly whether the target of the relocation has ValueFlags::FUNCTION set? But I'd say it's worthwhile experimenting a bit to see in which cases the other linkers accept or error.

• Whether R_X86_64_64 to local symbols should error or emit dynamic reloc

If lld errors here, then I'd say it'd be good to do the same. We can always relax it later to accept it like GNU ld if it turns out to be problematic. But it also depends a bit on how hard the implementation is. If it ends up significantly simpler to accept rather than error, then I'd be open to that.

[davidlattimore]

It's fine, possibly even preferable to fix each case in a separate PR. So don't feel that you need to fix them all in this PR. Note that github isn't very good at reading intention when issues are referenced, so saying "partial fix for X" is just as likely to close X when the PR is merged. I usually just put "Issue X", since that definitely doesn't close the issue.