We have mostly harmless data races when running
BinaryContext::calculateEmittedSize() in parallel, while performing
split function pass. However, it is possible to end up in a state
where some MCSymbols are still registered and our clean up
failed. This happens rarely but it does happen, and when it happens,
it is a difficult to diagnose heisenbug. To avoid this, add a new
clean pass to perform a last check on MCSymbols, before they
undergo our final emission pass, to verify that they are in a sane
state. If we fail to do this, we might resolve some symbols to zero
and crash the output binary.
Details
- Reviewers
Amir maksfb - Group Reviewers
Restricted Project - Commits
- rG62a2feff5784: [BOLT] Fix state of MCSymbols in lowering pass
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Thank you for fixing this non-determinism!
LGTM sans clang-format issue. I wish there was a way to clear symbol state without doing the series of dyn_casts.
bolt/lib/Passes/BinaryPasses.cpp | ||
---|---|---|
581 | static |
bolt/lib/Passes/BinaryPasses.cpp | ||
---|---|---|
581 | this is under an anonymous namespace |
bolt/lib/Passes/BinaryPasses.cpp | ||
---|---|---|
581 | Exactly. You are supposed to use static instead of anonymous namespaces. It is about readability. If I look at resetMCSymbolState, then I cannot see that it has internal linkage. static makes the job simpler. |
bolt/lib/Passes/BinaryPasses.cpp | ||
---|---|---|
581 | Oh, I didn't know/remember this rule changed in LLVM coding standards. Sounds good, thanks. Ref for other readers: https://llvm.org/docs/CodingStandards.html#id58 |
This new pass typically runs in the order of less than 100ms for very large binaries, so it does not introduce any important overhead to our pipeline.
static