57 lines · plain
1; REQUIRES: aarch642; RUN: rm -rf %t && split-file %s %t3 4; RUN: llvm-mc -filetype=obj -triple=arm64-apple-darwin %t/a.s -o %t/a.o5; RUN: %lld -dylib -arch arm64 --no-tail-merge-strings -order_file %t/orderfile.txt %t/a.o -o - | llvm-nm --numeric-sort --format=just-symbols - | FileCheck %s6; RUN: %lld -dylib -arch arm64 --tail-merge-strings -order_file %t/orderfile.txt %t/a.o -o - | llvm-nm --numeric-sort --format=just-symbols - | FileCheck %s --check-prefix=MERGED7 8; CHECK: _str29; CHECK: _str110; CHECK: _superstr211; CHECK: _superstr312; CHECK: _superstr113; CHECK: _str314 15; str1 has a higher priority than superstr1, so str1 must be ordered before16; str3, even though superstr1 is before superstr3 in the orderfile.17 18; MERGED: _superstr219; MERGED: _str220; MERGED: _superstr121; MERGED: _str122; MERGED: _superstr323; MERGED: _str324 25;--- a.s26.cstring27 _superstr1:28.asciz "superstr1"29 _str1:30.asciz "str1"31 _superstr2:32.asciz "superstr2"33 _str2:34.asciz "str2"35 _superstr3:36.asciz "superstr3"37 _str3:38.asciz "str3"39 40; TODO: We could use update_test_body.py to generate the hashes for the41; orderfile. Unfortunately, it seems that LLVM has a different hash42; implementation than the xxh64sum tool. See43; DeduplicatedCStringSection::getStringOffset() for hash details.44;45; while IFS="" read -r line; do46; echo -n $line | xxh64sum | awk '{printf "CSTR;%010d", and(strtonum("0x"$1), 0x7FFFFFFF)}'47; echo " # $line"48; done < orderfile.txt.template49 50;--- orderfile.txt51CSTR;1236462241 # str252CSTR;1526669509 # str153CSTR;1563550684 # superstr254CSTR;1044337806 # superstr355CSTR;262417687 # superstr156CSTR;717161398 # str357