diff options
author | Peter Maydell <peter.maydell@linaro.org> | 2024-07-23 16:14:54 +0100 |
---|---|---|
committer | Peter Maydell <peter.maydell@linaro.org> | 2024-07-29 16:58:14 +0100 |
commit | b42ba4ea4322357fcbfcb0e6e613d79ede84de64 (patch) | |
tree | 98e14b763d94726fa9827e1db7d71d68d977991c /module-common.c | |
parent | b69c95e718ba83fac6d5d725c4a79c4da808ab67 (diff) | |
download | qemu-b42ba4ea4322357fcbfcb0e6e613d79ede84de64.zip qemu-b42ba4ea4322357fcbfcb0e6e613d79ede84de64.tar.gz qemu-b42ba4ea4322357fcbfcb0e6e613d79ede84de64.tar.bz2 |
target/xtensa: Make use of 'segment' in pptlb helper less confusing
Coverity gets confused about the use of the 'segment' variable in the
pptlb helper function: it thinks that we can take a code path where
we first initialize it:
unsigned segment = XTENSA_MPU_PROBE_B; // 0x40000000
and then use that value as a shift count:
} else if (nhits == 1 && (env->sregs[MPUENB] & (1u << segment))) {
In fact this isn't possible, beacuse xtensa_mpu_lookup() is passed
'&segment', and it uses that as an output value, which it will always
set if it returns nonzero. But the way the code is currently written
is confusing to a human reader as well as to Coverity.
Instead of initializing 'segment' at the top of the function with a
value that's only used in the "nhits == 0" code path, use the
constant value directly in that code path, and don't initialize
segment. This matches the way we use xtensa_mpu_lookup() in its
other callsites in get_physical_addr_mpu().
Resolves: Coverity CID 1547589
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Acked-by: Max Filippov <jcmvbkbc@gmail.com>
Message-id: 20240723151454.1396826-1-peter.maydell@linaro.org
Diffstat (limited to 'module-common.c')
0 files changed, 0 insertions, 0 deletions