aboutsummaryrefslogtreecommitdiff
path: root/libsframe
diff options
context:
space:
mode:
authorMike Frysinger <vapier@gentoo.org>2024-01-06 23:16:41 -0500
committerMike Frysinger <vapier@gentoo.org>2024-01-08 20:01:05 -0500
commitb2ea48df925a6d41f63e88b26dbf3f17cde0f252 (patch)
tree90faff9a96d7518eb11b590eaa2327c3b28c67c8 /libsframe
parent707877ab59c6d0cbcb58cb5d467ab5f0d071a935 (diff)
downloadgdb-b2ea48df925a6d41f63e88b26dbf3f17cde0f252.zip
gdb-b2ea48df925a6d41f63e88b26dbf3f17cde0f252.tar.gz
gdb-b2ea48df925a6d41f63e88b26dbf3f17cde0f252.tar.bz2
sim: cgen: rework DI macros to avoid signed left shifts
The cgen code uses DI as int64_t and UDI as uint64_t. The DI macros are used to construct 64-bit values from 32-bit values (for the low and high parts). The MAKEDI macro casts the high 32-bit value to a signed 32-bit value before shifting. If this created a negative value, this would be undefined behavior according to the C standard. All we care about is shifting the 32-bits as they are to the high 32-bits, not caring about sign extension (since there's nothing left to shift into), and the low 32-bits being empty. This is what we get from shifting an unsigned value, so cast it to unsigned 32-bit to avoid undefined behavior. While we're here, change the SETLODI macro to truncate the lower value to 32-bits before we set it. If it was passing in a 64-bit value, those high bits would get included too, and that's not what we want. Similarly, tweak the SETHIDI macro to cast the value to an unsigned 64-bit instead of a signed 64-bit. If the value was only 32-bits, the behavior would be the same. If it happened to be signed 64-bit, it would trigger the undefined behavior too.
Diffstat (limited to 'libsframe')
0 files changed, 0 insertions, 0 deletions