[PowerPC] emitXCOFFRefDirective not creating relocation entries in increasing address order in the relocation table

[w2yehia]

ld: 0711-548 SEVERE ERROR: Object /home/wyehia/tmp/foo-20399d.o cannot be processed.
        RLD address 0x0 for section 1 (.text) is
        out of order. RLDs must be in ascending address order.

> dump -rvX64 foo.o

foo.o:

                        ***Relocation Information***
             Vaddr      Symndx  Sign  Fixup     Len      Type  Name
.text:  
        0x00000022  0x0000001d     0      0  0x000f TOC_ILodx  x
        0x0000002e  0x0000001f     0      0  0x000f TOC_ILodx  my_foo2
        0x00000032  0x00000021     0      0  0x000f TOC_ILodx  my_foo
        0x00000000  0x00000011     0      0  0x0000   Non_Rel  ifunc_sec          <<---------------------
        0x00000000  0x00000003     0      0  0x0000   Non_Rel  .__init_ifuncs
        0x00000086  0x00000023     0      0  0x000f TOC_ILodx  foo

This problem got exposed when implementing ifuncs on AIX in the compiler, where we had to generate .ref from a function.

[llvmbot]

@llvm/issue-subscribers-bug

Author: Wael Yehia (w2yehia)

[llvmbot]

@llvm/issue-subscribers-backend-powerpc

Author: Wael Yehia (w2yehia)

[w2yehia]

@redstar pointed out that a potential fix is in XCOFFWriter::recordRelocation where we can order the relocations before generating the relocation table, or change FixupOffsetInCsect to be the address of the last instruction (if such thing is possible).

[w2yehia]

It seems that FixupOffsetInCsect is zero by design: https://reviews.llvm.org/D152777
So we'll have to do a sort of the relocations before writing (to disk).

[w2yehia]

IBM-internal discussion that led to D152777: https://ibm-systems-z.slack.com/archives/C011Q66Q3MY/p1686637190186179?thread_ts=1685326409.301829&cid=C011Q66Q3MY

[w2yehia]

I reverted D152777 and ran LIT, and was able to reproduce the linker error described in D152777 in one of the tests (compiler-rt/test/asan/TestCases/asan_and_llvm_coverage_test.cpp).

Here's a reproducer:

> cat t.cpp
#include <stdio.h>
int foo() { return 1; }
int XXX = foo();
int main() {
  printf("PASS\n");
}

> clang -coverage t.cpp -fsanitize=address -c
> clang -m64  -coverage t.o -fsanitize=address
ld: 0711-547 SEVERE ERROR: Object t.o cannot be processed.
        RLD address 0x638 for section 2 (.data) is
        not contained in the section.

@mandlebug you theorized that when we emit the .ref as the last directive in a csect, we're creating the relocation on the next address rather than the last generated instruction/data, and it seems that is the case:

> dump -tvX64 t.o
[189]   m   0x00000620     .data     1  unamex                    __llvm_gcov_ctr_section
[190]   a4  0x00000018       0    0     SD       RW    -    -
[191]   m   0x00000620     .data     1  unamex                    __llvm_gcov_ctr
[192]   a4  0x000000bd       0    0     LD       RW    -    -
[193]   m   0x00000628     .data     1  unamex                    __llvm_gcov_ctr.1
[194]   a4  0x000000bd       0    0     LD       RW    -    -
[195]   m   0x00000630     .data     1  unamex                    __llvm_gcov_ctr.2
[196]   a4  0x000000bd       0    0     LD       RW    -    -
[197]   m   0x00000640     .data     1  unamex                    __llvm_internal_gcov_emit_arcs_args.0
[198]   a4  0x00000060       0    0     SD       RW    -    -

> dump -rvX64 t.o
                        ***Relocation Information***
             Vaddr      Symndx  Sign  Fixup     Len      Type  Name
.data:
        0x00000638  0x000000c9     0      0  0x0000   Non_Rel  __llvm_covinit

csect __llvm_gcov_ctr_section spans 0x620:0x638, while bytes 0x639:0x63f are padding between
csect __llvm_gcov_ctr_section and
csect __llvm_internal_gcov_emit_arcs_args.0
but are not part of any csect.
so having a relocation on address 0x638, which is not part of any csect, is what the linker is complaining about.