-
Notifications
You must be signed in to change notification settings - Fork 15k
[BOLT] Gadget scanner: improve handling of unreachable basic blocks #136183
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
atrosinenko
merged 5 commits into
main
from
users/atrosinenko/bolt-gs-unreachable-basic-blocks
Jun 25, 2025
Merged
Changes from 3 commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
a4c4163
[BOLT] Gadget scanner: improve handling of unreachable basic blocks
atrosinenko d005309
Fix handling of unreachable loops of BBs
atrosinenko c2f82d9
Improve estimation of the initial state of unreachable BBs
atrosinenko cdc20ab
Rephrase warning message
atrosinenko e14dce9
Add a FIXME
atrosinenko File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIUC, with this patch basic blocks that are not part of the CFG as reconstructed by BOLT are now also analyzed. These blocks are analyzed with a pessimistic initial state.
There are 2 possible cases why a basic block is not part of the CFG:
In this case, the pessimistic assumptions are probably going to cause more false positives in these "not-part-of-the-CFG basic blocks" than if BOLT was able to reconstruct the CFG?
If all my assumptions above are correct, maybe the warning messages should state that more clearly, for example, something like "Warning: function {function_name} has seemingly unreachable basic blocks, possibly due to limits in how bolt can reverse engineer the CFG. This may lead to more false positives being reported in these basic blocks"
Having said just that, I'm also thinking that maybe this is similar to the situation where BOLT cannot create a CFG at all. If so, should we (are we already?) producing a warning then too? But maybe that would produce way too many warnings?
Would it be correct to say that in this case all reports against these dead code basic blocks would be false positives?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the suggestion, I rephrased the warning message in cdc20ab, though I used less concrete wording: not "more false positives" but "the analysis quality may be degraded". Even if incomplete CFG can only result in false positives when caused by jump table not being understood by BOLT (the only reason I observed in the wild so far), this seems to indicate the analyses in BOLT are somewhat broken for the function, so I would not be sure that this cannot result in lots of false negatives under different conditions.
All the reports for dead code are probably false positives, but if the particular code is actually seemingly dead (maybe some precompiled snippet for JIT or something...), then nothing can be told for sure, but this is hardly an issue of the scanner :) Anyway, this does not look like a widespread issue worth implementing a workaround at first glance, but maybe scanning large code bases will prove the opposite...
Considering the functions without CFG at all, printing a warning for them sounds reasonable, but this turned out to break a lot of tests relying on
CHECK-NOT: function_name_nocfg- added a FIXME in e14dce9 for now.