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