For comparison, here are corresponding output lines for:

* LLD-LTO for arm64:

I  72558 Section .rodata: has 100.0% of 6760029 bytes accounted for from 143788 symbols. 0 bytes are unaccounted for.
I  72589 * 137640 have source paths assigned (95.7%)
I  72663 * Padding accounts for 44365 bytes (0.7%)
I  72666 * 6035 anonymous symbols account for 471833 bytes (0.0%)
I  72743 * Contains 119210 string literals. Total size=2862834, padding=40116
I  72789 * Contains 41518 aliases, mapped to 14932 unique addresses (721454 bytes saved)
I  72843 * 215 symbols have shared ownership (2622 bytes)


* LLD (no ThinLTO) for arm (32-bit):

I  47613 Section .rodata: has 100.0% of 6336992 bytes accounted for from 139138 symbols. 0 bytes are unaccounted for.
I  47659 * 138470 have source paths assigned (99.5%)
I  47762 * Padding accounts for 12680 bytes (0.2%)
I  47864 * Contains 118629 string literals. Total size=2895211, padding=9332
I  47919 * Contains 39146 aliases, mapped to 14063 unique addresses (706460 bytes saved)
I  47990 * 811 symbols have shared ownership (2497 bytes)

It makes more sense to compare arm64 with arm (32-bit) for LLD no ThinLTO, since the generated .o files are ELF files.

So llvm-nm output of arm (32-bit) has outputs like:
00000000 r .L.str
00000017 r .L.str.1
00000019 r .L.str.2
0000001e r .L.str.3
00000026 r .L.str.4

, which SuperSize uses to find string literals. These fields are missing for arm64. Worse, the addresses corresponding to 'r' are all '0000000000000000'. Potential causes:
- Additional debug info flag needs to be enabled?
- llvm-nm needs is not properly dumping data.
- LLVM does not store the data we need in .symtab.

Meanwhile dumping strings in arm64 .o files do not show ".L.str".

This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.