<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Implement cstring literal merging"
href="https://bugs.llvm.org/show_bug.cgi?id=50563">50563</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Implement cstring literal merging
</td>
</tr>
<tr>
<th>Product</th>
<td>lld
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>MachO
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>jezreel@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>gkm@fb.com, jezreel@gmail.com, llvm-bugs@lists.llvm.org, smeenai@fb.com
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=24903" name="attach_24903" title="ld64 cstring misalignment crash">attachment 24903</a> <a href="attachment.cgi?id=24903&action=edit" title="ld64 cstring misalignment crash">[details]</a></span>
ld64 cstring misalignment crash
Mergeable cstring literals are found under the `__TEXT,__cstring` section. In
contrast to ELF, which puts strings that need different alignments into
different sections, clang's Mach-O backend puts them all in one section.
Strings that need to be aligned have the `.p2align` directive emitted before
them, which simply translates into zero padding in the object file.
I *think* ld64 extracts the desired per-string alignment from this data by
preserving each string's offset from the last section-aligned address. I'm not
entirely certain since it doesn't seem consistent about doing this; but perhaps
this can be chalked up to cases where ld64 has to deduplicate strings with
different offset/alignment combos -- it seems to pick one of their alignments
to preserve. This doesn't seem correct in general; see the attachment, which
can induce ld64 to produce a crashing binary just by linking in an additional
object file that only contains cstrings and no code.
Moreover, this scheme seems rather inefficient: since unaligned and aligned
strings are all put in the same section, which has a single alignment value, it
doesn't seem possible to tell whether a given string doesn't have any alignment
requirements. Preserving offset+alignments for strings that don't need it is
wasteful.
In practice, the crashes seen so far seem to stem from x86_64 SIMD operations
on cstrings. X86_64 requires SIMD accesses to be 16-byte-aligned. So for now,
I'm thinking of just aligning all strings to 16 bytes on x86_64. This is indeed
wasteful, but implementation-wise it's simpler than preserving per-string
alignment+offsets. It also avoids the aforementioned crash after deduplication
of differently-aligned strings. Finally, the overhead is not huge: using
16-byte alignment (vs no alignment) is only a 0.5% size overhead when linking
chromium_framework.
This is a pretty unprincipled heuristic, but we can always revisit it later.
For now, I'd like to see how many CFStrings ICF can remove after we dedup the
cstrings.
(Another heuristic I considered: clang seems to only emit SIMD operations for
strings > 16 bytes, so I tried only aligning these longer strings, but it was a
difference of 0.1% -- didn't seem worth the additional implementation
complexity.)</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>