When setting up the chain, we copy over the bucket's previous symbol
index, assuming that this index will be 0 (STN_UNDEF) for an unused
bucket (marking the end of the chain). When linking with --no-rosegment,
however, unused buckets will in fact contain the padding value, and so
the hash table will end up containing invalid chains. Explicitly
zero-initialize the buckets to fix this problem. Also explicitly
zero-initialize the chain entry for STN_UNDEF; I don't think this is
actually necessary, but it doesn't hurt, and should make the hash table
identical both with and without --no-rosegment.
Details
Details
- Reviewers
• espindola grimar ruiu - Commits
- rG62840bccf2ea: Merging r322259: --------------------------------------------------------------…
rGd79bbf4474d5: [ELF] Fix SysV hash tables with --no-rosegment
rL322642: Merging r322259:
rLLD322259: [ELF] Fix SysV hash tables with --no-rosegment
rL322259: [ELF] Fix SysV hash tables with --no-rosegment
Diff Detail
Diff Detail
- Repository
- rL LLVM
Event Timeline
ELF/SyntheticSections.cpp | ||
---|---|---|
1839 ↗ | (On Diff #129376) | I'd do memset(Buf, 0, Size) here just like we did at beginning of GnuHashTableSection::writeTo(). That's less error-prone and easy to understand than filling holes with zeros. Zero-clearing a contiguous chunk of memory is very fast, so we don't have to minimize the number of bytes written to memory in this case. |
Comment Actions
LGTM
ELF/SyntheticSections.cpp | ||
---|---|---|
1839–1841 ↗ | (On Diff #129394) | If you copy-n-paste this comment, update the other comment to refer this one, so that we won't end up having the identical comment in two functions. |