[lld][ELF][test] Fix excessive output file size in loongarch-add-sub.s

[xen0n]

Summary

Initially the .rodata section came before .text, hence sharing its
segment with the program header sitting at a small offset, pushing the
output file size to ~72GiB (the file was sparse though, so not much is
really written). This breaks on 32-bit platforms and is irrelevant to
the feature being tested, so re-order the two sections so .text gets
processed first, and both sections get their own segment.

This addresses the issue found by the clang-armv8-lld-2stage builder:

https://lab.llvm.org/buildbot/#/builders/178/builds/5340

[xen0n]

We need to cherry-pick this to the LLVM 17 release branch, otherwise other 32-bit platforms will also fail on this test.

[xry111]

LGTM.

FWIW GNU assembler does not agree with this test case: it complains relocation out of range for baz and quux.

[MaskRay]

LGTM and LGTM for cherry picking to release/17.x

[SixWeining]

I have created a cherry-pick issue https://github.com/llvm/llvm-project/issues/64140.

lld/test/ELF/loongarch-add-sub.s

 # REQUIRES: loongarch
 
 # RUN: llvm-mc --filetype=obj --triple=loongarch64-unknown-elf %s -o %t.la64.o
 
-# RUN: ld.lld --section-start=.rodata=0x1234567890 --section-start=.text=0x9876543210 %t.la64.o -o %t.la64
+# RUN: ld.lld --section-start=.text=0x1234567890 --section-start=.rodata=0x9876543210 %t.la64.o -o %t.la64
 # RUN: llvm-readelf -x .rodata %t.la64 | FileCheck --check-prefix=CHECK %s
 # CHECK:      section '.rodata':
-# CHECK-NEXT: 0x1234567890 10325476 98badcfe 80b9fd41 86000000
-# CHECK-NEXT: 0x12345678a0 80b9fd41 80b980
+# CHECK-NEXT: 0x9876543210 10325476 98badcfe 804602be 79ffffff
+# CHECK-NEXT: 0x9876543220 804602be 804680
 
+.text
 .global _start
-
 _start:
 1:
     break 0
 
 .rodata
 2:
     .dword 0xfedcba9876543210