Clang does not align certain sections in its object files, so when they are linked it is possible that the runtime relocation sections are not aligned. This causes the linker to re-align them, but the value of "rt_psrelocs_start" is set before the realignment, so when the dll is loaded it looks in the wrong place for the relocations and fails.
This can be fixed by forcing realignment by adding the line ". = ALIGN(4);" to the linker script immediately before setting rt_psrelocs_start.
This bug was also reported to MinGW64: https://sourceforge.net/p/mingw-w64/bugs/769/
The master branch has been updated by Nick Clifton <email@example.com>:
Author: Marc <firstname.lastname@example.org>
Date: Fri Nov 9 11:13:50 2018 +0000
Allow for compilers that do not produce aligned .rdat sections in PE format files.
* scripttempl/pep.sc (pe.sc): Ensure rdata_runtime_pseudo_relocs
* scripttempl/pep.sc (pep.sc): Likewise.
It sounds a bit suspicious that clang is not aligning the relocs, but
I see no reason why the linker scripts should not cope with the fact,
so I have checked in your patch.
(In reply to Nick Clifton from comment #2)
> It sounds a bit suspicious that clang is not aligning the relocs
Just for discussion, clang doesn't align the relocs (as they are produced by ld) - I presume you meant why clang doesn't align the rdata section.
Judging from the linker script, wouldn't it mostly be a case of clang producing object files with .rdata sections that end with an uneven number of bytes? And I don't see how that would be suspicious. I haven't dug into a full case of this happening though.
In any case, the applied patch certainly is right though.
(I'm just arguing because I don't think there is a bug to be fixed on the clang side wrt this, as someone is led to believe in https://bugs.llvm.org/show_bug.cgi?id=39754.)