Looks like a typo from the past code changes.
Details
Diff Detail
Event Timeline
Added in-code comments with details
lldb/source/Plugins/Process/Utility/ARMUtils.h | ||
---|---|---|
48–49 | These lines were unreachable prior to the fix due to the default label with no break skipping to case 0. Past code history suggests that was accidental. | |
314–315 | Same here. Past code history suggests the break was missing by accident, i.e the default case was added to satisfy a static code checker without the intent to modify the execution flow. |
lldb/source/Plugins/Process/Utility/ARMUtils.h | ||
---|---|---|
29 | Looking at the codepaths and the reason this function exists, it's either called with a 2 bit number which is the "type" field of an instruction, or it's not called because the type is known to be SRType_RRX already. In the enum ARM_ShifterType SRType_RRX would be 4, which wouldn't fit the 2 bit expectation. So I think we can safely re-enable this assert and move the two unreachable lines up here. I didn't get any test failures doing so and I don't see a codepath that could hit it. (but it would be fairly easy for future changes to make this mistake since it's not very obvious from the types, so an assert is good here) | |
314–315 | This part LGTM. This "bits" function is returning uint32 so the compiler can't know it'll only be in a 2 bit range. |
Code update to address the comments
Differential Revision: https://reviews.llvm.org/D131244
lldb/source/Plugins/Process/Utility/ARMUtils.h | ||
---|---|---|
49 | This is now dead code? |
Looking at the codepaths and the reason this function exists, it's either called with a 2 bit number which is the "type" field of an instruction, or it's not called because the type is known to be SRType_RRX already.
In the enum ARM_ShifterType SRType_RRX would be 4, which wouldn't fit the 2 bit expectation.
So I think we can safely re-enable this assert and move the two unreachable lines up here. I didn't get any test failures doing so and I don't see a codepath that could hit it.
(but it would be fairly easy for future changes to make this mistake since it's not very obvious from the types, so an assert is good here)